1 / 15

Netconf Notifications

Netconf Notifications. Sharon Chisholm Hector Trevino IETF 67 November 2006. Issues. The -03 version of the Notification draft was well-reviewed. Most of those comments were resolved and incorporated into the -04 version. Exceptions were listed

fchristine
Download Presentation

Netconf Notifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Netconf Notifications Sharon Chisholm Hector Trevino IETF 67 November 2006

  2. Issues • The -03 version of the Notification draft was well-reviewed. Most of those comments were resolved and incorporated into the -04 version. Exceptions were listed • https://ops.ietf.org/lists/netconf/netconf.2006/msg01223.html • This package includes unresolved issues from the last update and new issues raised against -04 on the mailing list. • They have been reordered to try to put the issues requiring more discussion earlier in the package

  3. Issues – Data Models • Why do we need to query the notification subscriptions? [BL] • http://ops.ietf.org/lists/netconf/netconf.2006/msg01226.html • Does the schema contain the right information to query [AB]

  4. Transport Mappings • Which transports must be supported in version 1.0? • - Document packaging • Include in Notifications RFC or create 2 separate RFCs? 4 separate RFCs? • - SOAP needs a lot of specification work; not going to hold up the entire • work item waiting for this document. [AB] • - SOAP could use Ajax Push design [TG] • http://ops.ietf.org/lists/netconf/netconf.2006/msg01216.html

  5. Instance Validation • Changes introduced in later versions of the Netconf base protocol mean that instance documents of notifications (and rpc-replies), don’t appear to be validating • <xs:complexType name="dataInlineType"> • <xs:complexContent> • <xs:restriction base="xs:anyType"/> • </xs:complexContent> • </xs:complexType>

  6. Issues – RPC Methods • create-subscription • why isn't there a stop-time in the replay capability? [BL] • why stop notifications after replay (e.g. no tail -f mode) [BL]

  7. minAccess/ config-notconfig • Issue 9 from pre-03 list • The documentation currently defines appinfo to annotate information in the document. Primarily the maxAccess clause and some module Identity. We can’t publish with a dependency on this document since it would block us. • a.      We talked about just publishing a short little document that would define the appInfo bits we needed, as appose to full data specification • b.      Andy has suggested instead of maxAccess, moving to config or not config, which I think could also work.  State versus statistics would also be a nice distinction to be able to make, but perhaps that can wait.

  8. Relationships in Schema • The data model currently uses keyref to associate subscriptions to specific instances of named profiles • Is this too complex and under-described in document [AB]

  9. Cardinality of Streams • Are you suppose to be able to associate more then one stream with a single subscription [AB]

  10. Issues -Security Considerations • Need paragraph stating that security threats are handled during NETCONF session establishment, and the notification mechanism does not introduce any new threats, since any data available through <notification> can also be made available to the <get> RPC. [DR]

  11. Misc Detailed Comments • Not necessary to allow combining named profiles and filters [AB] • stop notifications (2.3) • Wants to remove "or some mechanism outside the scope of this spec" • There is only <kill-session> unless and until the WG creates something else. [AB] • capability strings in 3.1 are wrong: • (correct format) • urn:ietf:params:netconf:capability:{name}:1.0

  12. Issues - Syntax • General XSD issues) • Why do we need 3 namespaces? [BL] • The XML Schema should start with a top level element (e.g. <top>) and specify the containing elements all the way down. [BL] • http://ops.ietf.org/lists/netconf/netconf.2006/msg01226.html

  13. Misc Comments • NETCONF stream • The default stream of NETCONF is well described. Doesn’t want it to be optional [AB] • Note in Montreal we said when it wasn’t specified it would be NETCONF • The schema does not reflect that it is optional.

  14. Misc Comments • notification replay should not be a separate capability [AB] • Note that we agreed to a separate capability in Montreal • replayCompleteNotification • Why do we need to signal the end of replay with a special notification? Why is this detail needed at all? [AB]

  15. Issue- Documentation • assorted comments and corrections (10/24/06 email) [BL] • http://ops.ietf.org/lists/netconf/netconf.2006/msg01227.html • assorted comments and corrections (10/24/06 email) [MB] • http://ops.ietf.org/lists/netconf/netconf.2006/msg01228.html

More Related