Re: [yang-doctors] [Netconf] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-10

"Eric Voit (evoit)" <evoit@cisco.com> Wed, 21 March 2018 23:49 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDB712AAB6; Wed, 21 Mar 2018 16:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, 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 aEggA4T7Qrf7; Wed, 21 Mar 2018 16:49:49 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B278E12D72F; Wed, 21 Mar 2018 16:49:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8469; q=dns/txt; s=iport; t=1521676188; x=1522885788; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=a+4mjavUgQn8SwdXAoKX+3DJ6NImxKlnnJZY4/pjUrw=; b=Rb6BB/BhjJRhTUQ79CWoQ1zBhdUJ4D/uYHLdYIeKj1AosobBtsaZWTfj CoR5pce02nzdePqfviebLAul2O+80To1kOmtXH7ph/2EqVrCImBUy4wd0 3ZbeoymjzF8xvgCbGTWSaH1xbiXme7uoagfnXKcxLCyqz8jQEYgJVEVwj k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQBX77Ja/4kNJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPWFwKAqLUY0MgXGBEJMoFIF1CyOEFkwCg1YhNBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUlAQEBAwE6PQIFCwIBCA4HAw0REDIlAgQBDQUIE4RrCA+uU4hEgXYFh?= =?us-ascii?q?0OBU0CBDoMKgxMCAYE2CgEBBgJIhQMgA4djhgeKUQkCjyqBTYZyhHmQDwIREwG?= =?us-ascii?q?BJQEcOIFScBWCfYJLjgRwAY1AgSCBFgEB?=
X-IronPort-AV: E=Sophos;i="5.48,341,1517875200"; d="scan'208";a="87006516"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 23:49:45 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w2LNnjKg013677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Mar 2018 23:49:45 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Mar 2018 19:49:44 -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; Wed, 21 Mar 2018 19:49:44 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "andy@yumaworks.com" <andy@yumaworks.com>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "draft-ietf-netconf-subscribed-notifications.all@ietf.org" <draft-ietf-netconf-subscribed-notifications.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-10
Thread-Index: AQHTvP9v9ARZDJYwE0mt60SgwmbJJaPbVUpw
Date: Wed, 21 Mar 2018 23:49:44 +0000
Message-ID: <f675d003813f4212975167c35ed751c6@XCH-RTP-013.cisco.com>
References: <152115125179.4495.9379808208471040239@ietfa.amsl.com> <20180316.091848.1111565634082704625.mbj@tail-f.com>
In-Reply-To: <20180316.091848.1111565634082704625.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.61.71.125]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/Lwj1btotQMc6ao23i_L-IaO3Pi0>
Subject: Re: [yang-doctors] [Netconf] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-10
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2018 23:49:51 -0000

Hi Martin,

> From: Martin Bjorklund, March 16, 2018 4:19 AM
> 
> Hi,
> 
> Andy Bierman <andy@yumaworks.com> wrote:
> 
> [...]
> 
> > 2.4.2.1.  Replay Subscription
> >
> >    If the "replay-start-
> >    time" contains a value that is earlier than content stored within the
> >    publisher's replay buffer, then the subscription MUST be rejected,
> >    and the leaf "replay-start-time-hint" MUST be set in the reply.
> >
> >    >> this is a significant and bad change from RFC 5277 behavior
> >    >> the start-time says "send all events that you have stored
> >       since this time" The server sends its oldest event and does
> >       not reject the request.  This draft incorrectly interprets
> >       the request as "the server MUST have an event stored at least
> >       this old"
> 
> I agree, and I have pointed this out in earlier reviews.

In our past discussions, it looked like you were ok after reading Yves requirement here:

https://www.ietf.org/mail-archive/web/netconf/current/msg12154.html

Beyond this functional requirement, the design pattern used is that an establish-subscription RPC must send the exact parameters accepted by the publisher.


> If a client sends a too early time, and the server doesn't send the optional
> hint, the client will have to guess the time.  Not very robust.
> 
> If the motivation is that the client should be informed that he might have
> missed some notifs b/c the replay-start-time is too early, this information
> can be passed in the rpc-reply from establish-subscription instead.

Yes this could be done.  But this doesn't follow the design pattern of making the client explicitly ask for what they want.  Consistent design patterns do matter.

> >    If a "stop-time" parameter is included, it MAY also be earlier than
> >    the current time and MUST be later than the "replay-start-time".  The
> >    publisher MUST NOT accept a "replay-start-time" for a future time.
> >
> >    >> MUST be later (if the start-time) if supplied
> >    >> MAY be before current time?  Inconsistent with start-time
> >       MUST have events that exist
> >    >> MUST NOT accept future start-time different than 5277, but OK
> >       because that was a bad requirement
> 
> I have also pointed out in earlier reviews that the requirement that the
> replay-start-time cannot be in the future is problematic:

Yes.  The thinking both of you passed along drove this modification.

>   I know that this text is also present in RFC 5277, but I think it
>   needs to be changed.  Which current time?  Probably the server's,
>   but how would a client know that?  This is a problem that we faced
>   when implementing 5277.   I think we should remove this
>   requirement, since it doesn't add any value anyway.
> 
> IMO, if the server gets a replay-start-time that is later than the latest stored
> notif, it will send a <replay-completed> notif, and then move on.  This is a
> very simple behavior that doesn't rely on synchronized clocks or anything
> like that.

The text which I suggested back to Andy :

   If the "replay-start-time" is later the scope of time covered by the
   replay buffer, then the publisher MUST send a "replay-completed"
   notification immediately after the after a successful establish-
   subscription RPC response.

> [...]
> 
> > 2.5.2.  Creating a Configured Subscription
> >
> >        In this case, when there is
> >    something to transport for an active subscription, transport specific
> >    call-home operations will be used to establish the connection.
> > When
> >
> >    >> is this normative or is callhome optional-to-implement?
> >
> >    With active configured subscriptions, it is allowable to buffer event
> >    records even after a "subscription-started" has been sent.  However
> >    if events are lost (rather than just delayed) due to replay buffer
> >    overflow, a new "subscription-started" must be sent.  This new
> >    "subscription-started" indicates an event record discontinuity.
> >
> >   >> this is confusing to send multiple "subscription-started" events.
> >
> >    To see an example at subscription creation using configuration
> >    operations over NETCONF, see Appendix A of
> >    [I-D.draft-ietf-netconf-netconf-event-notifications].
> >
> >    >> IMO the examples should be moved to this draft
> 
> +1

But those examples are transport specific.  This will make the document less applicable for other transports.

> [...]
> 
> 
> > 2.7.1.  subscription-started
> > 2.7.2.  subscription-modified
> >
> >   >> what is the value of returning all the input or configuration
> >     parameters in these notifications?  For a dynamic subscription,
> >     the only receiver just sent that info and does not need it.
> >     For a configured subscription, that data can be read from
> >     the configuration datastore.
> 
> I agree.  Removing these redundant parameters would also simplify the
> models quite a bit.

I replied on the thinking here to Andy. 

Basically it is possible that you could only send the contents of the leafref for dynamic subscriptions.  However this introduces complexity, as should have a notification type and set a different expectation of what would be populated with a dynamic subscription.  So in the end, we can do it.  But it makes the model more complicated (although the tree gets smaller.)   

Also this assumes that the receiver can do a read.  (For IoT, this might not be the case.)

Beyond that, if the parameters change multiple times on a configured subscription, you might not be quick enough to do a read in time to know the parameters during a transient period.

Finally, a configured receiver might have lost state, so why not refresh the full set?  There is little cost to refreshing the full view of the subscription.

So in the end, this a complex simplification drives error cases and more variations to process for the receiver.

> [...]
> 
> > 4A) message encoding
> >
> >   feature encode-json {
> >     description
> >       "This feature indicates that JSON encoding of notification
> >        messages is supported.";
> >   }
> >
> >   feature encode-xml {
> >     description
> >       "This feature indicates that XML encoding of notification
> >        messages is supported.";
> >   }
> >
> >   identity encodings {
> >     description
> >       "Base identity to represent data encodings";
> >   }
> >
> >   identity encode-xml {
> >     base encodings;
> >     if-feature "encode-xml";
> >     description
> >       "Encode data using XML";
> >   }
> >
> >   identity encode-json {
> >     base encodings;
> >     if-feature "encode-json";
> >     description
> >       "Encode data using JSON";
> >   }
> >
> >   typedef encoding {
> >     type identityref {
> >       base encodings;
> >     }
> >     description
> >       "Specifies a data encoding, e.g. for a data subscription.";
> >   }
> >
> >     leaf encoding {
> >       type encoding;
> >       mandatory true;
> >       description
> >         "The type of encoding for the subscribed data.";
> >     }
> >
> >   >> IMO all YANG definitions related to message encoding should
> >      be removed because they are in conflict with existing protocols.
> >      NETCONF defines XML encoding. HTTP already defines
> >      media type handling for message encoding (Accept, Content-Type)
> >      There is no definition how to use JSON with NETCONF.
> 
> +1

Per response to Andy:

It is true that it is possible to populate unsupported mixtures of protocol and encoding.  However:
(a) for configured subscriptions, we must be able to select different encodings for a single type of transport 
(b) checking what is an invalid/unsupported combination for a platform is quite easy

While it is possible to build a structure which enforces valid combinations with YANG, this would add complexity, especially as vendor custom encodings will also become new identities under the base encoding.   If there is some YANG structure which exists for such enforcement of protocol and encoding (which would be something likely common with other solutions), do you have a link?

Thanks,
Eric

> 
> /martin