Using%20XML%20Schema%20to%20define%20NETCONF%20Content

1
Using XML Schema to define NETCONF Content

• Sharon Chisholm schishol_at_nortel.com
• Alex Clemm alex_at_cisco.om
• TJ Tjong jtjong_at_cisco.com

2
Overall concept
Option 1 define XSD directly
Netconf Data Definitions (XML)
Server XSD
Server XML (mgmt info as a whole, e.g. on device)
NDL (XSD)
Option 2 map automatically
describe, validate
XML-based model(more abstract,
friendlyshorthand providingresource-based
structure)
Client XSD
Client XML (mgmt info as part of mgmt request)
describe, validate
Instance information
Hierarchy-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
reference
configData
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
  
• ------------------------------------
  ----------------------------------

5
DHCP XML Schema
configuration
configuration
configuration
configuration
6
DHCP XML Schema
Off-the-shelf tool graphical viewing, editing,
validation of generic constraints of the model
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
Proposal Metamodel NDD Constructs
9
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 inheritances 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

10
Library of configData and operationalData

• Library Package
• Common CD, OD
• Use inheritance, if necessary
• Common ER, TD
• No MRs or limited number of MRs with
• no MR Inheritance
• Implementation Package
• Interrelated MR
• in-line CD, OD
• implement Library CD, OD
• If reference polymorphism is required
• MR implements Library MR (one level of
  specialization only.)

Lib-2
Lib-1
operationalData OD2 attribute od2_1
attribute od2_2
configData CD1 attribute cd1_1
attribute cd1_2
Definition Reuse and conformance to a common CD
OD
Impl-x
managedResource MR-a reference Lib.Interface
interfaces configData attribute
myAttr1 attribute myAttr2
configData implements Lib-1.CD1
attribute cd1_1 attribute cd1_2
operationalData implements Lib-2.OD2
attribute od2_1 attribute od2_2

Polymorphic Reference can point to
various interface types
Impl-y
managedResource SerialInterface
implements Lib.Interface
Impl-z
managedResource EthernetInterface
implements Lib.Interface
11
Library Definitions
12
Library Definitions .. continued
13
Reuse of Library managedResource Definitions
14
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

15
Requirements Compliance

• 3.1. Consequences of NETCONF
• 3.1.1. Notification Definition (Agreed)
  Yes
• 3.1.2. Notification Get (NOT Agreed)
  Yes
• 3.1.3. Locking (Agreed)
  Yes
• 3.1.4. All Base Operations (Agreed)
  Yes
• 3.1.5. Define new NETCONF Operations (Agreed)
  Yes
• 3.1.6. Separation of Operations and Payload
  (Agreed) Yes
• 3.1.7. Error Annotation (Agreed)
  Yes
• 3.1.8. No Mixed Content (Agreed)
  Yes (statement, not syntax)
• 3.2. Model Representation Requirements
• 3.2.1. Human Readable (Agreed)
  Yes
• 3.2.2. Machine Readable (Agreed)
  Yes
• 3.2.3. Textual Representation (Agreed)
  Yes
• 3.2.4. Document Information (Agreed)
  Yes
• 3.2.5. Ownership and Change Control (Agreed) Yes
  
• 3.2.6. Dependency Risk Reduction (Agreed) Yes
• 3.2.7. Diff-Friendly (Agreed)
  Yes
• 3.2.8. Internationalization and Localization
  Yes
• 3.2.8.1. Descriptions using Local Languages
  (Agreed) Yes

16
Requirements Compliance

• 3.4. Instance Data Requirements
• 3.4.1. Default Values on the Wire (Agreed) Yes
• 3.4.2. Ordering
• 3.4.2.1. Ordered Lists (Agreed)
  Yes
• 3.4.2.2. Order within Containers (NOT Agreed)
  Yes
• 3.4.2.3. Interleaving (NOT Agreed)
  Yes (with appInfo)
• 3.4.3. Validation
• 3.4.3.1. Validate Instance Data (Agreed)
  Yes
• 3.4.3.2. Tools to Validate Instance Data (NOT
  Agreed) Yes
• 3.4.4. Instance Canonicalization (Agreed)
  Yes
• 3.4.5. Character Set and Encoding (Agreed) Yes
  
• 3.4.6. Model Instance Localization (NOT Agreed)
  No (disagree wit requirement)
• 3.5. Semantic Richness Requirements
• 3.5.1. Human-Readable Semantics (Agreed) Yes
• 3.5.2. Basic Types (Agreed)
  Yes
• 3.5.3. Handling Opaque Data (Agreed)
  Yes
• 3.5.4. Keys
• 3.5.4.1. Define Keys (Agreed)
  Yes
• 3.5.4.2. Deep Keys (NOT Agreed)
  Yes

17
Requirements Conformance

• 3.5.8. Characterize Data (Agreed)
  Yes
• 3.5.9. Defaults
• 3.5.9.1. Default Values (NOT Agreed)
  Yes
• 3.5.9.2. Dynamic Defaults (NOT Agreed)
  No
• 3.5.10. Formal Constraints
• 3.5.10.1. Formal Description of Constraints
  (Agreed) Yes
• 3.5.10.2. Multi-element Constraints (NOT Agreed)
  No
• 3.5.10.3. Non-Key Uniqueness (Agreed)
  Yes
• 3.5.11. Units (Agreed)
  Yes
• 3.5.12. Define Actions (NOT Agreed)
  Yes

18
Requirements Compliance

• 3.6. Extensibility Requirements
• 3.6.1. Language Extensibility
  Yes
• 3.6.1.1. Language Versioning (Agreed) Yes
• 3.6.1.2. User Extensions (NOT Agreed) Yes
• 3.6.1.3. Mandatory Extensions (NOT Agreed) No
  (not recommended)
• 3.6.2. Model Extensibility
• 3.6.2.1. Model Version Identification (Agreed)
  Yes
• 3.6.2.2. Interaction with defaults (NOT Agreed)
  Yes
• 6.2.3. Conformance Interference (NOT Agreed) Yes
  
• 3.6.2.4. Obsolete Portions of a Model (Agreed)
  Yes
• 3.6.3. Instance Data Extensibility
• 3.6.3.1. Schema Version of Instance (NOT Agreed)
  No (want to maximum interoperability between
  versions)
• 3.6.3.2. Interaction with default Values (NOT
  Agreed) Yes
• 3.6.3.3. Backwards Compatibility (Agreed) Yes
• 3.6.3.4. Forwards Compatibility (NOT Agreed) Yes
  
• 3.7. Talking About Conformance
• 3.7.1. Conformance to the Modeling Language (NOT
  Agreed) Yes
• 3.7.2. Conformance to a Model (Agreed) Yes
• 3.8. Techno-Political Constraints

19
BACKUP
20
Alternative Reuse of Library configData
Definitions
21
NDD to XSD Translation

• NDD package gt XSD package
• MR, CD, OD gt complexType element
• For server-xsd sequence
• For client-xsd sequence of choice
• References and Attributes gt complexType elements

22
Original annotated-dhcp-instance.xml
Using dhcp-options XSD complexType extension
23
Base (library) dhcp-options complexType
Derived dhcp-options using complexType extension
(object extension)
24
Base dhcp-options complexType
Global element to be used in any extension