Netconf%20Notifications

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/ms
  g01223.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/msg
  01226.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/msg
  01216.html

5
Instance Validation

• Changes introduced in later versions of the
  Netconf base protocol mean that instance
  documents of notifications (and rpc-replies),
  dont appear to be validating
• ltxscomplexType name"dataInlineType"gt
• ltxscomplexContentgt
• ltxsrestriction base"xsanyType"/gt
• lt/xscomplexContentgt
• lt/xscomplexTypegt

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
  cant 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
  ltnotificationgt can also be made available to the
  ltgetgt 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 ltkill-sessiongt unless and until
  the WG creates something else. AB
• capability strings in 3.1 are wrong
• (correct format)
• urnietfparamsnetconfcapabilityname1.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. lttopgt) and specify the containing
  elements all the way down. BL
• http//ops.ietf.org/lists/netconf/netconf.2006/msg
  01226.html

13
Misc Comments

• NETCONF stream
• The default stream of NETCONF is well described.
  Doesnt want it to be optional AB
• Note in Montreal we said when it wasnt 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/msg
  01227.html
• assorted comments and corrections (10/24/06
  email) MB
• http//ops.ietf.org/lists/netconf/netconf.2006/msg
  01228.html