NETCONF Monitoring Schema

1
NETCONFMonitoring Schema

• draft-ietf-netconf-monitoring-schema-03
• IETF-73, Nov 2008, Minneapolis
• Björklund, Chisholm, Scott

2
Updates in -03

• Issues/Actions from IETF-72 addressed
• Terminology clarified (schema, model) draft
  updated
• Data types ongoing (next slide)
• Incorporated comments from mailing list. Main
  content changes
• Additional descriptions for parms, including data
  types
• Clarified mandatory (must) and optional
  (should) content
• Aligned RPC description with that in other drafts
• Added IANA considerations and proposed Capability
  Identifiers
• and removed URL reference to IANA list of
  existing capabilities
• XSD updates renamed data type for clarity
  NETCONFDatastoreType
• lt number of other comments addressed - see last
  slide for detailed list of changesgt

3
Data types Ongoing discussion

• Open item from IETF-72
• Some data types in this draft should be common,
  however, externally available, agreed XSD
  definitions are not yet available
• Draft defines ipAddress and hostName
• Some mailing list and offline discussions, main
  points raised
• Concensus that common data type definitions are
  desirable however
• acknowledgement that a number of initiatives to
  do this to date (not just for NETCONF) have taken
  long periods of time and/or not yielded desired
  results
• other RFCs exist with their own definitions of
  potentially common data types (eg EPP)
• unrealistic to expect this working group to
  create IETF wide definitions scope here would be
  common data types for NETCONF usage only
• netmod is undertaking similar work but
• timing would prevent completion of monitoring
  draft (per current charter)
• the definitions in the draft are aligned with
  those in draft-ietf-netmod-yang-types

4
Data Types Proposals

• Two main options discussed to date
• A) Delay work until netmod data type work
  completes
• to align data types
• to ensure the retrieval mechanism covers all
  netmod requirements (modules/sub-modules, naming,
  versioning, etc)
• B) Proceed with current definitions
• RFC can be updated in future pending outcome of
  netmod work
• this may not be the only draft impacted, esp. as
  WG adopts more content drafts

5
Next Steps

• Further reviews of v-03
• Continued discussion on data type issue.
  Proposals will be taken to mailing list for
  further inputs.

6
Draft v-03 detailed changes

• aligned use of terminology (per action item at
  IETF72)
• schema refers to the schema used to define the
  monitoring data model  (ie XSD schema for
  monitoring)
• "data model" is used for references to the
  monitoring content
• schema is used in the RPCs (get-schema) as it
  refers to manipulating the schema (not the
  instance data)
•  per action item to discuss alignment with other
  standardized NETCONF
•     - an offline discussion (details to follow in
  separate posting) is underway 
• updates from comments received on mailing list
• updated Introduction to better explain the
  necessity of this work
• removed UTC assumption on time references
• added clear usage of MUST and SHOULD (sec 2,
  2.1.1)
• removed unused references in Terminology
• 2.1.2  re-ordered description of partial locks
  to emphasize 'lockedNodes' takes priority over
  selection
• removed IANA URL reference
• updated references
• XSD update  changed 'ConfigurationDatastoreType'
  to 'NETCONFDatastoreType' 
• added IANA considerations section for proposed
  capabilities
• updated Yang Appendix with caveat that it is
  subject to change based on netmod work
• other comments received, which did not result in
  a change to the draft (open to further discussion
  and update)    - 2.1.6  request to add count of
  session closure reasons (close, kill, transport
  drop).  Agree with value of having these for a
  network element but think these may be better
  handled as security or transport OMs (or logs)
  since these apply to both NETCONF and non-NETCONF
  management sessions 

7
Thank You !