Transcript Netconf Notifications Sharon Chisholm Hector Trevino IETF 67

Netconf Notifications
Sharon Chisholm
Hector Trevino
IETF 67
November 2006
Issues
 The -03 version of the Notification draft was wellreviewed. 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
Issues – Data Models
Why do we need to query the notification
subscriptions? [BL]
http://ops.ietf.org/lists/netconf/netconf.2006/msg
01226.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]
 http://ops.ietf.org/lists/netconf/netconf.2006/msg
01216.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
<xs:complexType name="dataInlineType">
• <xs:complexContent>
 <xs:restriction base="xs:anyType"/>
• </xs:complexContent>
</xs:complexType>
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
<notification> can also be made available
to the <get> 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 <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
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/msg0122
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 email) [BL]
http://ops.ietf.org/lists/netconf/netconf.2006/msg
01227.html
assorted comments and corrections
(10/24/06 email) [MB]
http://ops.ietf.org/lists/netconf/netconf.2006/msg
01228.html