[Netconf] mbj's WGLC comments on netconf-event-notifications-08

[Martin Bjorklund <[e-mail]>]

Hi,

Here are my WGLC comments on
draft-ietf-netconf-netconf-event-notifications-08


o  On p. 3, theres a missing " (which messes up the colors in the
   emacs mode I use)

   OLD:

     SHOULD NOT"

   NEW:

     "SHOULD NOT"

   There's another one on p. 5:

   OLD:

      responses to an establish-subscription request) or "modify-
      subscription-error-datastore (for error responses to a modify-

   NEW:

      responses to an establish-subscription request) or "modify-
      subscription-error-datastore" (for error responses to a modify-


o  Section 3

  As I have noted before, you mustn't require the :interleave
  capability to be supported.  That capability is for 5277 only.  This
  new mechanism *requires* that rpc's can be sent while there are
  active subscriptions, so there is no need for a capability.

  Remove this section.


o  Section 4

  What is the reason for not allowing 5277 subscriptions on the same
  session as these new subscriptions?

  AFAICT this should just work fine, and no special rule is needed.


o  Section 5

  You write:

   A NETCONF publisher MUST support XML encoding of RPCs and
   Notifications.

  This is already specificed in RFC 6241.  You are not changing this,
  so this sentence should be removed.


o  Section 5

  You write:

   A NETCONF publisher supporting
   [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the
   "NETCONF" event stream identified in that draft.

  This is already specificed in that draft. You are not changing this,
  so this sentence should be removed.


o  Section 6.2

  (editorial, and clarified)

  OLD:

   For a configured subscription, there is no guarantee a transport
   session is currently in place with each associated receiver.  In
   cases where a configured subscription has a receiver in the
   connecting state and the protocol configured as NETCONF, but no
   NETCONF transport session exists to that receiver, the publisher MUST
   initiate a transport session via NETCONF call home [RFC8071], section
   4.1 to that receiver.  Until NETCONF connectivity is established and
   a subscription-started state change notification is successfully
   sent, that receiver MUST remain in a status of either "connecting" or
   "timeout".

  NEW:

   For a configured subscription, there is no guarantee a transport
   session is currently in place with each associated receiver.  In
   cases where a configured subscription has a receiver in the
   "connecting" state (see section 2.5.1 of [RFCXXXX] and the protocol
   is configured as NETCONF, but no
   NETCONF transport session exists to that receiver, the publisher MUST
   initiate a transport session via NETCONF call home [RFC8071], section
   4.1 to that receiver.  Until NETCONF connectivity is established and
   a "subscription-started" state change notification is successfully
   sent, that receiver MUST remain in either the "connecting" or the
   "timeout" state.

  OLD:

   If the call home fails because the publisher receives receiver
   credentials which are subsequently declined per [RFC8071],
   Section 4.1, step S5 authentication, then that receiver MUST be
   assigned a "timeout" status.

  NEW:

   If the call home fails because the publisher receives receiver
   credentials which are subsequently declined per [RFC8071],
   Section 4.1, step S5 authentication, then that receiver MUST be
   placed in the "timeout" state.

  OLD:

   If the call home fails to establish for any other reason, the
   publisher MUST NOT progress the receiver to the "active" state.
   Additionally, the publisher SHOULD place the receiver into a
   "timeout" status after a predetermined number of either failed call
   home attempts or NETCONF sessions remotely terminated by the
   receiver.

  NEW:

   If the call home fails to establish for any other reason, the
   publisher MUST NOT progress the receiver to the "active" state.
   Additionally, the publisher SHOULD place the receiver into the
   "timeout" state after a predetermined number of either failed call
   home attempts or NETCONF sessions remotely terminated by the
   receiver.

  OLD:

   NETCONF Transport session connectivity SHOULD be verified via
   Section 4.1, step S7.

  NEW:

   NETCONF Transport session connectivity SHOULD be verified as
   described in [RFC8071], Section 4.1, step S7.



o  Section 7

  You write:

   Notification messages transported over NETCONF will be identical in
   format and content to those encoded using one-way operations defined
   within [RFC5277], section 4.

  "identical in content"?  What does this section tell me?


o  Section 8

   o  "error-app-tag" with the value being a string that corresponds to
      an identity associated with the error, as defined in
      [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6

  This needs to explained better.  See also my WGLC comments on the
  other drafts.


  Also, I don't think the 5th bullet is complete; it doesn't mention
  "establish-subscription-error-stream" for example.


  What is this section trying to tell me that isn't already said, e.g.
  in section 3.8 of the push draft.  Maybe the other drafts should be
  less specific and all such text moved here.  As it is now it is not
  quite clear.


o  Section 8

  You write:

   Note that "error-path" does not need to be included with the "rpc-
   error" element, as subscription errors are generally not associated
   with nodes in the datastore but with the choice of RPC input
   parameters.

  This is a misconception how error-path works.  Please remove this
  sentence.  For info, check RFC 6241.


o  Appendix A.2.1

  I think it is useful to show an example of something that is easily
  missed; that notifications can be sent at any time:

  I suggest:

  OLD:

            |    establish-subscription    |
            |----------------------------->|
            | RPC Reply: OK, id = 23       |
            |<-----------------------------|
            |                              |
            |                              |
            | notification message (for 22)|
            |<-----------------------------|

  NEW:

            |    establish-subscription    |
            |----------------------------->|
            | notification message (for 22)|
            |<-----------------------------|
            | RPC Reply: OK, id = 23       |
            |<-----------------------------|
            |                              |
            |                              |
            | notification message (for 22)|
            |<-----------------------------|


o   Appendix A.2.1

  The example in Figure 3 is not correct.

  The example in Fixgure 5 is not correct wrt namespace.

  Hmm, it seems many examples are wrong.  I strongly suggest that you
  set up automatic testing of all your examples.  If you for some
  reason don't do that, please let me (and the WG) know so that we can
  validate all examples in detail manually.  Meanwhile, I will not
  check all examples.




/martin