Re: [Netconf] LC on subscribed-notifications-10

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 13 March 2018 13:44 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 A71E212D944; Tue, 13 Mar 2018 06:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 xZ5PXP-BdhUP; Tue, 13 Mar 2018 06:44:12 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D93126C83; Tue, 13 Mar 2018 06:44:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8286; q=dns/txt; s=iport; t=1520948651; x=1522158251; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=99ZRvxuPFwDetJo4HGScbJPSJwnCDQmCHB4IGSU51p0=; b=CjHdXgsj8Uyf1m7FMX6NSdiJvEkr3l4RbhYPlZvzc/pesKDbLc/fTqOi djL8izmkDAUE/eUyYjqVeuHCmJ8WzB9/5JaB4LDgiR7QK1iPssOuzk4hn e3HPnHBDxBwMbbZkUWauzpmvYHohRbd5977umFQyIffrKBLzu1Pc1S3aa A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AACk1Kda/5JdJa1WBxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDUIFVMoNGih2NdIIEexuUMYIVCoF7gyoCGoMGITQYAQI?= =?us-ascii?q?BAQEBAQECayeFIwEBAQMBIxFDBwsCAQgVBQIIAR0CAgIwFRACBAEaE4R1CKt?= =?us-ascii?q?VgiaIYIIVgQ2EKIIugVaBZoJ4NoUOgxuCYgSIMoZ7iykJApBYgW2HSoU0jmu?= =?us-ascii?q?CNgIREwGBKwEeOIFScBU6gkSERo1AKoEHgRgBAQE?=
X-IronPort-AV: E=Sophos;i="5.47,464,1515456000"; d="scan'208";a="370102148"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2018 13:44:10 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w2DDiAb7013237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Mar 2018 13:44:10 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Mar 2018 09:44:09 -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; Tue, 13 Mar 2018 09:44:09 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, Kent Watsen <kwatsen@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-subscribed-notifications@ietf.org" <draft-ietf-netconf-subscribed-notifications@ietf.org>
Thread-Topic: [Netconf] LC on subscribed-notifications-10
Thread-Index: AQHTuiDhP4UPxNeFY0CSJ8tCCoPN1aPM98TAgAFCjQD//+BDwA==
Date: Tue, 13 Mar 2018 13:44:09 +0000
Message-ID: <660a1ba93e014329a5ce99c096b83fea@XCH-RTP-013.cisco.com>
References: <DA8A1569-826D-4744-B780-90CDA064D0BD@juniper.net> <f9096b71-26b7-eda3-6ddc-2983b693a2f5@cisco.com> <8d4f4193c6694fe387d284d7b74c9b09@XCH-RTP-013.cisco.com> <48b60b6f-03c4-87e8-9905-f30d23c936d3@cisco.com>
In-Reply-To: <48b60b6f-03c4-87e8-9905-f30d23c936d3@cisco.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/VmB8X760ZpPiS5-W_EyRuVkaouc>
Subject: Re: [Netconf] LC on subscribed-notifications-10
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 13 Mar 2018 13:44:14 -0000

Hi Rob,

Reducing to the open dialogs...

> From: Robert Wilton, March 13, 2018 6:27 AM
> >> 2. Intro:
> >>    - Should security be somewhere in the intro section?
> > Do you see a particular need to emphasize security here?  Not sure why there
> should be a specific break-out here.
> Only to make it clear that it has been considered, and the draft provides a
> solution for it.

Inserted "and access permissions" in the second sentence to make it:

"Effectively this enables a "subscribe then publish" capability where the customized information needs and access permissions of each target receiver are understood by the publisher before subscribed event records are marshaled and pushed."

> >> - Steam: Is this really a set, or a sequence.  Perhaps ... "A
> >> continuous chronologically ordered sequence of events ..."?  If you
> >> change this, then perhaps grep for usage of "set" in the draft to see
> >> if they should be changed to sequence.
> > I like the addition of "chronologically", put that word in.  Regarding
> "sequence": with "ordered" we likely have that covered sufficiently.  Plus RFC-
> 5277 used  "set", so this is closer match to the original stream definition.
> I still strongly prefer calling it a sequence, because I think that is what it is :-)
>
> I quickly looked up a couple of definitions of stream in computer science
> literature and they all refer to them as sequences not sets.  Is the steam being
> referenced to this draft that same as what a normal software engineer would
> think of as a stream?
> 
> Is a stream ever allowed to contain duplicate values, e.g. on a replay it is
> possible to put the same events into the stream?

Event records are not be repeated on a subscription, even with replay.

>  If events are always unique
> then set is fine, otherwise set just seems like the incorrect term.

I really have no problem with "sequence".  The only issue is that we had requests from the original authors of RFC-5277 to keep the stream definition as close to the original as feasible.   If anyone else wants "sequence" and there are no objections, I am absolutely happy to convert.

> >> 8 2.4. Dynamic subscriptions
> >>
> >> - Would writing "event streams" be better than "targets"?
> > As dynamic subscriptions also apply to datastores (as augmented by yang-
> push), it is better to leave the more general term.
> OK, I think that I'm still struggling to create a good mental picture of how
> everything fits together.
> 
> I assumed that subscriptions only subscribe to event streams (e.g. from first
> sentence in section 1).  Hence, I was assuming that in the case of YANG push,
> that the change notifications to a datastore would effectively be a new event
> stream that could be subscribed to.  Are you saying that it is something
> else?  This might need to be clarified somewhere.

Actually what you were assuming was the original definition of "stream".  I.e., it was how stream was first defined in 2014 in yang-push up until -v04 in 2016.   But with the advent of NMDA, we wanted to adopt the definitions of "datastore" rather than create a mapping that forced the NMDA datastores to be associated 1:1 with stream names.

More is described in yang-push.  Note that In the yang module, target is a 'choice' statement with only a single case explored within subscribed-notifications.  So detailing in this document what is expressed as an actual choice in yang-push seemed confusing. 
 
> >
> >> - Diagram in 2.4.1, I found this diagram a bit tricky to read/interpret.  One
> >> particular question: Can you modify a subscription for a suspended receiver.
> > There is a line from receiver suspended for this, so yes.
> I think that I find it confusing as to what is an external event coming
> from a subscriber or receiver vs internal state changes.
> 
> OK, so I think that I have finally figured out what this diagram is
> meant to be showing :-)
> 
> Hence, I think that it might help to explicitly list the external events
> below the diagram:
> 
> - External events from a subscriber: establish-subscription,
> modify-subscription, ...

As each of these has its own section in the document, I am hesitant to add lots of verbal complexity to the diagram.  If other people think this would be helpful, it certainly could and should be added.

> - Internal states: start, receiver-ACTIVE, receiver-SUSPENDED, end.

In the text above the diagram, I added the sentence "Each state is shown in its own box".  Other text does describe the internal states.

> >> - The text mentions the publisher rejecting a subscription, when can this
> >> happen?
> > Actually it says "any" not "a".  The implication is that no other effects
> anywhere based on a rejected subscription request.  E.g., don't try to guess
> which subscription to delete.
> >
> > But there is still a case for "a".  What if a subscriber (with identical
> credentials) established the referenced subscription on a different transport
> session?  The delete still should not work unless it comes on the original
> transport.
> The first sentence of that paragraph already states that it is on the
> same transport session.  My interpretation of the current text is that a
> publisher can arbitrarily choose not to cancel a subscription.  I think
> that the text would be better if it was more explicit.
> 
> E.g. perhaps replace: " If the publisher rejects the request, the
>     request has no impact whatsoever on any subscription.
> 
> with something like:
> 
> "If the delete request does not match a known subscription id of a
> subscription established on the same transport session, then it MUST be
> rejected with no changes to the system".
 
Ok.  Made it:
If the delete request does not match a known subscription established on the same transport session, then it MUST be rejected with no changes to the publisher.

Thanks,
Eric

> > Appreciated, Thanks Again!
> > Eric
> Thanks,
> Rob