Using DSDL plus annotations for Netconf data modeling

1
Using DSDL plus annotations for Netconf () data
modeling

• Rohan Mahy
• rohan_at_ekabal.com
• draft-mahy-canmod-dsdl-01

2
What is DSDL?

• DSDL Document Schema Data Languages
  http//dsdl.org
• An ISO family of standards
• DSDL uses a modular approach to schema languages
• Part 2 Relax NG - traditional schema language
  structure
• Part 3 Schematron - rule based validation
• Part 4 NVRL - validate parts of instance doc
  with different schemas/languages
• Part 5 DataType Library Language
• etc
• Annotations are encouraged as part of modularity
• My usage of Data Model
• A model for describing the semantics and syntax
  of (configuration and operational) data. Does
  not include verbs.

3
Why Relax NG for syntax?

• Easy to read and learn (Compact or XML)
• Used by W3C (XHTML, SVG, XML Sig, RDF)
• Better XML support than XSD
• robust native support for XML namespaces
• unifies elements and attributes
• unordered content supported
• describes which pattern is root element
• Convertible to XSD
• Patterns can be scoped to prevent conflicts from
  one module

4
Schematron - rule-based validation

• Rule-based validation based on XPath expressions.
• Supports reusable abstract patterns
• Validation can be split in phases based on
  context
• Implementer can use a Schematron validator or
  write their own native code to perform an
  equivalent validation check.

ltpatterngt ltrule context"//dhcpdhcp"gt
ltassert test"dhcpdefault-lease-time
lt dhcpmax-lease-time"gt Default
lease time cannot be larger than maximum lease
time lt/assertgt lt/rulegt lt/patterngt
5
Semantic Annotations

• Important annotations
• keys to uniquely identify elements in a list
• define relational integrity constraints
• insure data is relevant to operation containing
  it
• These annotations can be implemented in native
  code on device or converted to additional
  Schematron rules by XSLT

6
Extensibility

• Relax NG has a nice pattern-based extensibility
  mechanism
• redefine patterns completely
• combine by choice
• combine by interleave
• Can include external grammars and keep scopes
  separate (ex both dhcp.rnc and interfaces.rnc
  have an element-interface pattern)

• config-root.rnc
• default namespace "http//example.org/ns/root"
• start element-config
• element-config element config
• external "interfaces.rnc" ?
• external "dhcpextensions.rnc" ?
• dhcpextensions.rnc
• include "dhcp.rnc" base module
• include "dhcp-tz.rnc" timezone extension
• include "dhcp-wins.rnc" WINS server ext
• dhcp-tz.rnc
• namespace tz "http//example.org/ns/dhcp/timezo
  ne"
• element-dhcp-option element tztimezone
  token
• ?

7
Met nearly all requirements in RCDML draft

• Met ALL Netconf-specific requirements (Section
  3.1)
• Some highlighted unique features
• Compound keys / Deep keys
• ltsubnetgt
• ltprefixgt
• ltnetworkgt192.168.24.0lt/networkgt
• ltprefix-lengthgt24lt/prefix-lengthgt
• lt/prefixgt
• ltrangegt
• ltlowgt192.168.24.20lt/lowgt
• lthighgt192.168.24.250lt/highgt
• lt/rangegt
• lt/subnetgt
• Implementation Defaults
• Most defaults are valid per version of the
  schema.
• Formal validation w/ Schematron
• Can implement these rules via custom code from
  assert text, or automatically using a Schematron
  validator (free libraries in C, Java, C and
  Python)

8
Whats nice about this approach

• Reuse of appropriate schema languages and tools
  is a good thing.
• Modular architecture makes incremental
  implementation/deployment and additional reuse
  easier (add other parts of DSDL, use subset of
  Netconf solution for another IETF protocol).
• Being able to add data model information for
  existing IETF schemas (LDAP-enabled directories,
  SIP phone config files, early Netconf users) is a
  good thing.
• Making Schematron available for formal
  machine-readable validation to clients that want
  it is a good thing.

9
Schema Plus vs. Model Plus approach

• Pure Semantics
• UML / XMI
• OWL (without a specific serialization)
• Semantics some syntax (top down)
• Yang
• Kalua
• Schema some semantics (bottom up)
• DSDL annotations
• XSD annotations

10
Semantics vs. Syntax dilemma

• Pure semantic approaches can represent things we
  cannot easily represent in Netconf or even in XML
  syntax
• Many to many relationships (graph vs tree)
• Top down approaches can constrain legitimately
  good syntax and blur semantics
• element vs. attribute representation of terminal
  nodes
• not distinguishing semantically ordered content
  (sequence) from unordered content (bags)
• Bottom up approaches are not easily convertible
  to radically different syntax (ex CLI)

11
Upgrading schema to data model

• There are lots of XML-based schema in the wild
  (XSD and Relax NG).
• It seems very beneficial to be able to take an
  existing schema and turn it into a data model
  while maintaining backward syntax compatibility
• Folks who defined XSD for use with Netconf.
• Other IETF WGs that already defined syntax of
  their schema but want data modeling.
• Other schemas defined elsewhere that we want to
  import for Netconf.