more Notifications comments

[Andy Bierman <ietf@andybierman.com>]

Hi,

there is probably some overlap here, but I wanted to post this before
the meeting anyway...  We will try to address all the mailing comments
at the meeting.

Andy




- streamslist 
  Should create subscription to a single stream, not an
  arbitrary combination of streams by the manager

- startTime
  This replay is no different than using <get> on a
  notification log MIB.  The tail -f functionality
  is a more relevant usage of a special RPC

- combining filter and namedProfile is not really needed
  because one can just create a named profile that contains
  the exact required filter set, not combining them like this.

- <notification> contains a single child node call <data>
  It is a data model decision what is under the top level
  element.  Not sure if this will be a help or a problem
  later on.

- stop notifications (2.3)
  Remove "or some mechanism outside the scope of this spec"
  There is only <kill-session> unless and until the WG creates
  something else.

 - capability strings in 3.1 are wrong:
 
 (correct format)
 urn:ietf:params:netconf:capability:{name}:1.0

 - NETCONF stream
   Mandatory to implement but no specifics on what it means
   to actually support this stream.

 - <streams> parameter is missing means use the default NETCONF?
   The schema does not reflect this.  Why allow the parameter to
   be optional at all?

 - <relationships> element is schema?  What is this?
   No explanation anywhere.

 - <associatedNamedProfile> is unclear?
   Looks too complex, but no examples or any text explaining
   it, so hard to tell what this is for.

 - minAccess, maxAccess need to be removed because they assume
   an ACM that does not exist.  <appInfo> extensions will be
   defined as part of the ACM, not as part of the notification work.
 
 - Fields in <netconfSubscription> element (monitoring data model)
  
   - session-id
   - streams (list)
   - filter
   - associatedNamedProfile
   - lastModified
   - messagesSent (optional)
   - key

   == Have no idea what <key> is for.
   == Do not think any of this data is important to monitor.


  - notification replay should not be a separate capability
   listed in the <hello> exchange.  It is an attribute of
   a particular stream.

  - replayCompleteNotification
    Why do we need to signal the end of replay with a special
    notification?  WHy is this detail needed at all?

  - Framework for NETCONF Datamodel is not a WG document
    and must not be used in this document.  It is currently
    a normative reference, which will block this draft until
    the other draft is also a standards track RFC.