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

1
Using XML Schema to define NETCONF Content

• Sharon Chisholm
• schishol_at_nortel.com
• December 2007
• IETF 70

2
Background

• Draft created to capture offline discussions
  about requirements and potential solutions for
  how to define NETCONF content
• Current Version
• http//www.ietf.org/internet-drafts/draft-chisholm
  -netconf-model-07.txt

3
The approach

• Requirements
• Solution to define content to be exchanged
  between NETCONF client and NETCONF server.
• Similar to what we required to define standard
  MIBs
• Minus some things that dont seem necessary
  anymore
• Plus some additional meta data
• Uses XML Schema, plus defines appInfo tags to
  fill in gaps
• Enables use of abundant off the shelf tools
• Allowed us to get started right away

4
Areas of Requirements

• Conformance
• Fine Grain Conformance
• Operations on managed objects .
• Element Status
• Additional Conformance Information
• Backwards Compatibility
• Versioning
• Keys
• Defining Relationships
• Association Relationship
• Defining Notification Event Messages
• Considerations for Parse-ability
• Well-formed XML
• Naming
• Error Messages
• Schema Documentation
• Specifying Statistics, Status and Configuration
  Information

AppInfo Values Compliance
minAccess read, write, create . etc Mandatory
maxAccess Read, write, creaqte, etc Optional
status Current, Obsolete Optional
appErrors lttextgt Recommended
eventClass Fault, config, state, etc Optional
dataType configuration, status, state Optional
5
Modeling Considerations

• Modularity
• Data Types
• Elements and Attributes
• Naming implications of using XPATH
• Proper Tag Names
• Granularity of Data Model
• Avoid Mixed Content

6
Updates in -07

• Explained a few more benefits of the approach
• Updated notification definition to align with
  Notification ID
• Cleaned up examples to be more consistent and
  correct
• Deleted the section which outlined specific
  NETCONF operations against the data model since
  it didn't seem to have much to do with this
  document.
• General cleanup
• Added an appendix talking about the potential for
  a mapping to Yang

7
Requirements
Description XSD Relax NG Yang
1 Leverage existing widely used technology Yes Yes No. Can generated XSD
2 Be machine readable Yes Yes Yes (custom tools)
3 Be human readable Subjective Subjective subjective
4 Enable defining configuration data Yes Yes
5 Enable defining non-configuration data Yes Yes
6 Support defining keys Yes. Native keys Yes
7 Support defining cross references Partially. Would benefit from stealing solution from Yang Yes
8 Support characterizing data type Configuration, status, state Configuration, state
9 Default values No. Easily added Yes
10 Compliance Yes. Combination of native minOccurs, MaxOccurs and new minAccess Yes
11 Notification Definition Yes Yes
12 Object status Current and obsolete Current, obsolete and deprecated
13 Error annotation Yes yes
This list is not complete, but demonstrative of
the analysis we should probably do
8
(No Transcript)