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

Martin Bjorklund <mbj@tail-f.com> Fri, 08 June 2018 14:39 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B79130EB7 for <netconf@ietfa.amsl.com>; Fri, 8 Jun 2018 07:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk91jmX0Jbgl for <netconf@ietfa.amsl.com>; Fri, 8 Jun 2018 07:39:25 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC78130E8D for <netconf@ietf.org>; Fri, 8 Jun 2018 07:39:25 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 646791AE027A for <netconf@ietf.org>; Fri, 8 Jun 2018 16:39:24 +0200 (CEST)
Date: Fri, 08 Jun 2018 16:39:24 +0200 (CEST)
Message-Id: <20180608.163924.639364006777002795.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20180316.145936.984795473579499350.mbj@tail-f.com>
References: <20180316.145936.984795473579499350.mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/alZ1KKs9VD-Kub3Txfjjl0GYpD4>
Subject: Re: [Netconf] mbj's WGLC comments on netconf-event-notifications-08
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2018 14:39:28 -0000

Hi,

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


/martin


Martin Bjorklund <mbj@tail-f.com> 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
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>