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

[Martin Bjorklund <[e-mail]>]

Hi,

I haven't seen any reply to this WGLC review.


/martin


Martin Bjorklund <[e-mail]> wrote:
> 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
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>