Using DSDL plus annotations for Netconf (+) data modeling

1. Using DSDL plus annotations for Netconf (+) data modeling Rohan Mahy rohan@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. <pattern> <rule context="//dhcp:dhcp"> <assert test="dhcp:default-lease-time &lt;= dhcp:max-lease-time"> Default lease time cannot be larger than maximum lease time </assert> </rule> </pattern>

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. 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 "dhcp+extensions.rnc" ? } # dhcp+extensions.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/timezone" element-dhcp-option &= element tz:timezone { token }? Extensibility

7. Met nearly all requirements in RCDML draft • Met ALL Netconf-specific requirements (Section 3.1) • Some highlighted unique features • Compound keys / Deep keys <subnet> <prefix> <network>192.168.24.0</network> <prefix-length>24</prefix-length> </prefix> <range> <low>192.168.24.20</low> <high>192.168.24.250</high> </range> </subnet> • 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. What’s 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.