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

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 08 June 2018 16:30 UTC

Return-Path: <evoit@cisco.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 40CB2130F26 for <netconf@ietfa.amsl.com>; Fri, 8 Jun 2018 09:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 ubbF-Sfdcs74 for <netconf@ietfa.amsl.com>; Fri, 8 Jun 2018 09:30:28 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CDF130F23 for <netconf@ietf.org>; Fri, 8 Jun 2018 09:30:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11560; q=dns/txt; s=iport; t=1528475428; x=1529685028; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZsXez1/XDClLl0ZzySu3GhZbKH8CLuoMnj0c38dgYQ0=; b=f9696Cicv2J2+yQi3jal8kIHNWevVH3C6k4YTAa/N5pKaelxd9tFnx9c ovsz5SiucrLguN7mGVZguLtVSaFkakSGzocL+SBnl2UJGByA9rf5IMfG0 RDikem8fN9zt8msK82f+H8Kc64vMyrPZUZ7dYhQvGlu5AvszIxJS0mSSJ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AABUrhpb/5JdJa1UCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDGSpifygKi3KMZoF+lFIUgWQLGA+Df0YCgk0hNBgBAgE?= =?us-ascii?q?BAQEBAQJtHAyFKAEBAQMBAQElEzQJBwsCAQgOBwMNERAnCyUCBAESCIMcgXc?= =?us-ascii?q?ID6taM4hFgWMFiEOBVD+BD4MMggaBCwEBgTYShW0Ch0QIhGiBI4NYh0wJAoV?= =?us-ascii?q?riHaBRoN7h2+HaoIchwACERMBgSQdOIFScBU7gkOCIRd6AQ6CPIUUhT0Bb45?= =?us-ascii?q?zK4EBgRkBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,490,1520899200"; d="scan'208";a="126410856"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2018 16:30:27 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w58GUQKd024703 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jun 2018 16:30:27 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Jun 2018 12:30:25 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Fri, 8 Jun 2018 12:30:25 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] mbj's WGLC comments on netconf-event-notifications-08
Thread-Index: AQHT/zaJm894WSf8RUqPL+4NEHDjeKRWc+Xw
Date: Fri, 8 Jun 2018 16:30:25 +0000
Message-ID: <0e6e711ab209437e881335756c268e07@XCH-RTP-013.cisco.com>
References: <20180316.145936.984795473579499350.mbj@tail-f.com> <20180608.163924.639364006777002795.mbj@tail-f.com>
In-Reply-To: <20180608.163924.639364006777002795.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/dICFJzw0Yu3GMERUdFtsne7eJis>
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 16:30:31 -0000

> From: Martin Bjorklund, June 8, 2018 10:39 AM
> 
> Hi,
> 
> I haven't seen any reply to this WGLC review.

Hi Martin,

Below.  And with changes reflected in:
https://github.com/netconf-wg/notif-netconf/blob/master/draft-ietf-netconf-netconf-event-notifications-10.txt 

> /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"

Your text is reflected in git version

> >    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-

Based on comments with Kent, this has been turned into a more descriptive table format.

> > 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.

Done.

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

The biggest reason is that existing 5277 implementations can safely assume that only one subscription can be established on a NETCONF session.  And therefore all returned <notification> elements will belong to that subscription.    Even if the subscriber doesn't support subscribed-notifications or subsequently send an <establish-subscription>, without this constraint a configured subscription to the same receiver could inject notifications on the RFC-5277's NETCONF transport session.  (E.g., a <subscription-started> state change notification.)

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

It likely could on a well behaved RFC-5277 implementation.  But caution is needed as RFC5277 implementations hadn't previously needed to worry about such co-existence.

> > 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.

Previously changed this text to indicate the mandatory support of the "encode-xml" feature.

> > 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.

In subscribed-notifications, the "NETCONF" stream is defined, but it is not mandatory support.  Instead, just that the stream name is reserved.    There will be IoT clients out there which don't need the NETCONF stream. 

> > 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.

The git version is now...

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 as described in [I-D.draft-ietf-netconf-subscribed-notifications], section 2.5.1, and the "transport" for that subscription is "NETCONF", but no NETCONF transport session exists to that receiver (or all existing NETCONF transport sessions are currently supporting [RFC5277] subscriptions), then 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.

Your text is reflected in git version

> >   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.

Your text is reflected in git version

> >   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.

Update made

> > 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?

Tweaked the words to:

Notification messages transported over the NETCONF protocol will use the one-way operations defined within [RFC5277], section 4.

> > 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.

Current git version includes your requested updates, such as which base identity to use for each RPC, and the JSON encoding format for the identities.

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

There is a whole table on this is the current git version.

> >   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.

Alex is removing the text from the yang-push draft.

> > 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.

Removed

> > 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)|
> >             |<-----------------------------|

Added

> > 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.

Einar has since built an automated testbed for the examples.  Results are included in independent directories in the git repository:

https://github.com/netconf-wg/notif-netconf

Eric

> >
> >
> > /martin
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf