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  html 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

Issues – Data Models Why do we need to query the notification subscriptions? [BL]  html html  Does the schema contain the right information to query [AB]

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] html html

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 

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]

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.

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]

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

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 can also be made available to the RPC. [DR]

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 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

Issues - Syntax General XSD issues)  Why do we need 3 namespaces? [BL]  The XML Schema should start with a top level element (e.g. ) and specify the containing elements all the way down. [BL] 6.html 6.html

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.

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]

Issue- Documentation assorted comments and corrections (10/24/06 ) [BL]  html html assorted comments and corrections (10/24/06 ) [MB]  html html