NetConf Data Model draft-adwankar-netconf-datamodel-01.txt

1. NetConf Data Modeldraft-adwankar-netconf-datamodel-01.txt Sandeep Adwankar

2. Why Data Model? • Interoperability • Non-trivial implementation • <rpc> <Get> ifTable (UnDefined) </Get> • </rpc> • <rpc-reply> <Data> Nothing Defined </Data> • <rpc-reply>

3. Do we need information model? • Are relations important to be modeled • Is it just “ref” in XML schema, if so it is containment • Is aggregation important to be modeled • Yes, but isn’t it inherent to XML • Is abstraction layer important • Yes, and XML schema provides it • Is representing complex interrelationship important • Xpath allows retrieving complex content from bunch of simple elements

4. Do we need information model • Are graphical design methods (e.g. UML) important • Number of tools available for XML Schema that generates diagrammatic representation • Is having single common model important • XML allows transformation using technologies such as XSLT • Do we need one more information model • Allow translation mechanisms • E.g. CIM Provider in case of CIM • E.g. NGOSS information steward in case of SID

5. Survey of Data Models • Structure of Management Information • Structure of Policy Provisioning Information • Common Information Model • Device Description Framework • Web Services Distributed Management

6. Why XML Schema • Support range of predefined types allowing strong type well as constraints checks • Allows use of regular expressions • Allows reusable types and creation of new types with inheritance • Rich in constructs such as for grouping and for defining abstract layer • Tools available for graphical representation and code generation • Provides tools for translation of content (XSLT) and locating content (XPATH)

7. Data Model Design Objectives • Simple and Lightweight • Provide interoperability amongst NetConf entities • Allows derivation of the NetConf Data Model to develop model for each device • OO feature to inherit the data model and to minimize impact of changes in the data model • Evolutionary model that uses wealth of existing information • E.g. MibDepot offers access to 6200 SNMP MIBS • Provides standardized migration path for those MIBs instead of proprietary CLIs

8. Data Model Design Objectives • Minimize dependence on NetConf Protocol • Should be beyond just configuration • Minimal definition of data model • Not to define explicit containers, if a container hierarchy can be obtained through XPATH • Alignment of various data models at the level of exchange • Technologies such as XSLT can be used without creating a common schema/model • Aid in creating non-trivial implementations

9. Data Model Design • Every Managed Object inherits from a Generic Node • Each managed object value is simple type and can be type-checked or constraints checked • For container value indicates type of container such as either sub-tree, table, entry

10. Data Model Design • Each Managed Object definition must provide • Parent • Max Access • Status • Description • Managed object value is designed as an attribute to minimize hierarchy and since it is simple type • A container managed object definition includes references to other managed objects

11. Data Model Schema

12. sysDescr Definition <element name="sysDescr" > <complexType> <complexContent> <extension base="nc:NodeType"> <sequence> <element name="parent" type="nc:ParentName" fixed="system" minOccurs="0"/> <element name="maxAccess" type="nc:ReadAccess" minOccurs="0"/> <element name="status" type="nc:Status" fixed="current" minOccurs="0"/> <element name="description" type="nc:Description" fixed="A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software." minOccurs="0"/> </sequence> <attribute name="value" type="nc:DisplayString" use="required"/> </extension> </complexContent> </complexType> </element>

13. Naming • Must support relative URI based addressing • ./system/sysName • Should support Xpath • //sys:sysName/@sys:value • //if:ifEntry[if:ifMtu@if:value>’500’]

14. Naming++ • Locate managed objects • Select set of managed objects based on a set of criteria’s • Create container structure based on different managed object values • Create simple expressions such as (//if:ifEntry/if:ifInOctets/@if:value + //if:ifEntry/if:ifOutOctets/@if:value)*800 div (//if:ifEntry/if:ifSpeed/@if:value ) Corresponds to (ifInOctets + ifOutOctets) * 800 / ifSpeed

15. ACL • List of ACL entries that may include ACL of parent • ACL Entry • access list, a list of NetConf protocol operations • identifier list that groups accessors together • Access duration, duration over which an ACL entry is valid

16. ACL

17. ACL Example <nc:ACL> <nc:ACLEntry> <nc:access> <nc:Read> <nc:get-config/> ... <nc:get/> </nc:Read> </nc:access> <nc:Identifier> <nc:accessor> * </nc:accessor> </nc:Identifier> </nc:ACLEntry> </nc:ACL>

18. Compliance • Grouping construct to group related managed objects together • Schema compliance element provides compliance statement

19. Key Constraint • Define “key” constraints to ensure • Managed object must be present • Managed object value must be unique <key name="sysORKey"> <selector xpath="./sys:sysOREntry/sys:sysORIndex"/> <field xpath="@sys:value"/> </key>