1. Using XML Schema to define NETCONF Content Sharon Chisholm schishol@nortel.comschishol@nortel.com Alex Clemm alex@cisco.omalex@cisco.om TJ Tjong jtjong@cisco.comjtjong@cisco.com

2. Overall concept NDL (XSD) Netconf Data Definitions (XML) Server XSD Client XSD Server XML (mgmt info as a whole, e.g. on device) Client XML (mgmt info as part of mgmt request) describe, validate describe, validate Option 1: define XSD directly Option 2: map automatically Instance informationHierarchy-based structure XML-based model (more abstract, friendly “shorthand” providing resource-based structure) Non- NETCONF Content

3. Meta model Entities Managed Resource : the main entity Config Data: a group of (related) configuration data attributes Operational Data: a group of (related) operational data attributes Event Report Properties Key Attribute (instance id) Reference to other MR (child or peer) Configuration Attribute Operational Data Attribute Event Report Action Type Definitions Simple and Enumeration Types Complex Type (limited to sequence & choice) Constraints and Annotations Access, Value Constraints,... Annotations can be used for mapping data managedResource key attribute configData reference Elements/attribute operationalData Elements/attribute action eventReport typeDef

4. XML Schema Syntax Uses native XML Schema to define NETCONF content. Extends using small set of appInfo tags --------------------------------------------------------------------- | appinfo item | | Compliance | Default | --------------------------------------------------------------------- | minAccess | | Optional | oper - read | | | | | config –read, write | | maxAccess | | Optional | oper – read | | | | | config - read, write, create and delete| | status | | Optional | current | | appErrors | | Optional | | | eventClass | | Optional | | | infoType | | Mandatory | | | default | | Optional | | | keyref | | Optional | | | mustUse | | Optional | | | unordered | | | | | units | | | | ---------------------------------------------------------------------- Also possible to derive a client-specific XSD to enable better parsing with less knowledge of NETCONF-specific extensions (mustUse)

5. DHCP XML Schema configuration

6. DHCP XML Schema

7. Data definition syntax Syntax formally defined using XML Schema Native support of meta model More abstracted than XML Schema syntax – not just different syntax Managed Resources, the targets of CRUDX Relationships between them parent/child  maps to instance hierarchies peer  maps to references Config data, operational data Attributes with multiplicities, constraints,...

8. Reuse Component-based and inheritance-based model reuse Operational data, Configuration data Groupings of managed resource properties Assemble Managed Resources from existing config data and operational data definitions Promotes component-based data definitions Library data definitions intended for reuse Inheritance support for Managed Resources, Config Data, Operational Data Some limitations, e.g. no restrictions of existing definitions Designed to get inheritance’s best but discourage models that are too deep and fine-grained This is what you would standardize on Implementation data definitions to describe actual implementations Implement the definitions from library packages This essentially defines compliance, version variations between different vendor implementations

9. Library Definitions

10. Library Definitions.. continued

11. Reuse of Library managedResource Definitions

12. Strengths of the proposal Meets agreed requirements XSD, XML allow leveraging of off-the-shelf tools Simple yet powerful model for reuse Assemble managed resources from config and operational data building blocks Extend definitions from libraries Unique compliance model No separate compliance statements Implementation data definitions implement library data definitions A “Happy Medium” proposal Combine strengths of domain-specific languages with ubiquitous XML/XSD technology Leverage the best of object models while remaining rooted in component- and module-based management information definitions Allow for different model insertion points, giving users an option to define XSD models directly, or to define models (still XML-based) at a higher level of abstraction

13. BACKUP

14. configData managedResource key ndLib / ndImpl enumerationType operationalData action reference attribute eventAttribute configData operationalData simpleType complexType eventReport typeDef configDataDef managedResourceDef operationalDataDef eventReportDef condition constraint assert properties Contraints Proposal Metamodel – NDD Constructs

15. Alternative: Reuse of Library configData Definitions

16. NDD to XSD Translation NDD package => XSD package MR, CD, OD => complexType + element For server-xsd: sequence For client-xsd: sequence of choice References and Attributes => complexType elements

17. Original annotated-dhcp-instance.xml Using dhcp-options XSD complexType extension

18. Derived dhcp-options using complexType extension (object extension) Base (library) dhcp-options complexType

19. Global element to be used in ‘any’ extension Base dhcp-options complexType