Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: YangPush now)

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 27 July 2018 17:06 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 C9389130FF7; Fri, 27 Jul 2018 10:06:42 -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_MED=-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 GfsdeLE05c3z; Fri, 27 Jul 2018 10:06:40 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C39130FE9; Fri, 27 Jul 2018 10:06:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7279; q=dns/txt; s=iport; t=1532711199; x=1533920799; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8eKHRSfEerpmNwm25c8elxMfzp3ORpJkeF+nsgsyXws=; b=hdgktFTldZNvp8GfaTpAQI+CcDaG8Mr/shbdIhJK2pJfx4YtM7xhPHTp 9dZUZHQhex559eOL9kyX7aVNgXaYscYZ6uLp0L9iF34TrFKhC2GQ/H9IH JYFj1g1AKZ0ZTOL1rsrWbZWXNz1JYR+JShOORaJjODwUzmAWTki3xZTPl I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAQDOUFtb/5JdJa1YAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDIAQqY38oCpg1ggyXSwsjhANGAoJ7ITcVAQIBAQIBAQJ?= =?us-ascii?q?tHAyFNgEBAQMBOj8FCQICAQgOAgUDDREQGxclAgQODYJNTIF3CA+vX4o+BQW?= =?us-ascii?q?IfReBQT+BEYMSgxsCAYE/AQE/ERWEbyACmgsJAo8sjg6SDQIRFIEkMyKBUnA?= =?us-ascii?q?VgySCJRcRg2eEYYU+bwGNF4EfgRsBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,410,1526342400"; d="scan'208";a="149518967"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2018 17:06:38 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w6RH6cMm030589 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Jul 2018 17:06:38 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Jul 2018 13:06:37 -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, 27 Jul 2018 13:06:37 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Kent Watsen <kwatsen@juniper.net>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: [Netconf] YangPush now)
Thread-Index: AQHUJS2cZg8w9iUFbU+0+L6a3bxq1aSiIzgwgAC1BICAADdbkIAAY4AA///A6XA=
Date: Fri, 27 Jul 2018 17:06:37 +0000
Message-ID: <44256bc2840d4519aec9698770658c94@XCH-RTP-013.cisco.com>
References: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.cisco.com> <20180726221120.bv3mtlitoqqov2zm@anna.jacobs.jacobs-university.de> <1b58e76f527442c3a0fa34437b9f0cd4@XCH-RTP-013.cisco.com> <20180727060507.v7ljp6au4i46ezs3@anna.jacobs.jacobs-university.de> <643f32911e094f649c5007c5524112be@XCH-RTP-013.cisco.com> <20180727151922.ds74qzetcxiqg3is@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180727151922.ds74qzetcxiqg3is@anna.jacobs.jacobs-university.de>
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.234]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FK8KjWoMBpdfnPN4NnF9Kw3e-U4>
Subject: Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice? (was RE: YangPush now)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Jul 2018 17:06:43 -0000

> From: Juergen Schoenwaelder, July 27, 2018 11:19 AM
> 
> On Fri, Jul 27, 2018 at 03:03:21PM +0000, Eric Voit (evoit) wrote:
> >
> > I am fine either way if we incorporate the proposal or not.  Do you have
> the proposed construct is technically acceptable from the perspective of the
> YANG doctors?
> >
> 
> I understand Andy's comment not as a YANG issue 
> but a more general
> question whether it is desirable to have a standard without a mandatory to
> implement standard transport. This goes beyond YANG syntax.

Agree this is a relevant question.  Kent has made a "chair hat" request on this (with Andy on the 'to' line):
https://www.ietf.org/mail-archive/web/netconf/current/msg15169.html 

directly after Andy said he wanted to complete the current drafts in their current form:
https://www.ietf.org/mail-archive/web/netconf/current/msg15167.html 

So I am hoping that thread can be used to close on the mandatory-to-implement question if there are concerns there.

> > Also below are some thoughts on your other points...
> >
> > > From: Juergen Schoenwaelder, July 27, 2018 2:05 AM
> > >
> > > On Thu, Jul 26, 2018 at 11:35:04PM +0000, Eric Voit (evoit) wrote:
> > > >
> > > > One transport for all receivers was a voted WG decision at IETF 101.
> > > Some of the reasons from threads like:
> > > > https://www.ietf.org/mail-
> archive/web/netconf/current/msg13875.htm
> > > > l
> > > > https://www.ietf.org/mail-
> archive/web/netconf/current/msg14899.htm
> > > > l
> > > >
> > > > include:
> > > > (1) Simpler YANG model
> > > > (2) Simpler implementation possible as a single configured
> > > > subscription need be connected to only one transport
> > > > (3) Simpler implementation in that there is no expectation set on
> > > > the
> > > publisher that there will be no transport loss if the transport type
> > > is reconfigured for a particular receiver mid-subscription.
> > > > (4) Separation of implementation/troubleshooting concerns, as only
> > > > one transport is involved
> > > >
> > >
> > > With the proposed choice construct, I think
> > >
> > > (1) does not hold,
> >
> > Agree.
> >
> > > (2) seems unclear (why are multiple identitical subscriptions for
> > >     different transports cheaper than one subscriptions with multiple
> > >     transports?)
> >
> > Deep within the archived discussions, there were implementation
> > consideration points made about managing content and security
> > filtering across different transports and encodings for a single
> > subscription.  (E.g., what happens if filtering happens after encoding
> > and a change is made to the subscription or security filters, how do
> > you ensure the all filtering is applied at the same event boundary?)
> 
> There is only one standard filtering mechanism (NACM) and that does not
> filter on the encoding (and it would be a bad layer violation to filter on the
> encoding). Since encodings may be negotiated by a transport, the single
> encoding argument falls apart as well.

Martin has been adamant over the course of several years that the configuration of both transport and encoding be at the same level of the subscription (either at the receiver level, or the subscription level.)  Perhaps there are legitimate platform implementation considerations.  Previous versions of this debate can be seen at:
https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html

In the end, nobody has ever asserted use cases which demand that transports must be able to vary for a configured subscription.  So the previous WG consensus on this requirement seems reasonable despite the fact that the YANG modeling might end up more complicated (should Kent's empty choice statement proposal be deemed technically valid). 

> > > (3) I do not understand
> >
> > There are a set of implications which can be avoided.  For example
> controllers (which are receivers) will be consuming these events.  Controller
> based applications are less likely to have an expectation that there will no
> event replication for a single subscription-id for a publisher when that
> subscription-id transitions from one transport to another.
> 
> I am still clueless. What is a 'transitions of transport'? 

E.g., If somebody modifies a configured receiver from NETCONF to HTTP2.  Yes, the same issue could be asserted if you change the transport at the subscription level so that all receivers of all a subscription transition at once.  But at least you won't run into issues where there are there are transient deltas for a single subscription in the events delivered to different receivers of that same subscription.  

> My naive
> understanding of a subscription with a receiver and two transport is that
> the data goes to both. Or is the idea that these serve has failover backups?
> But then this may interact with similar features in the call-home documents
> (I did not check again but I think there were some failover mechanisms in
> there some time ago).

In discussions with Kent, there is a difference between failover (as covered by call-home), and dual live (which would be multiple receivers of the same subscription).
 
> > > (4) I do not understand (since you can easily distinguish the receiver
> > >     and label log messages by receiver)
> > >
> > > If we would be serious about simplification to lower the point of
> > > entry, we would have only a single receiver for a configured
> > > subscription. Allowing multiple receivers as long as they use the
> > > same transport seems like an arbitrary CLR.
> >
> > Yes, this was considered.  However there are use cases where identical
> event streams must be sent for receiver redundancy reasons.  The current
> design can support that possibility.  Beyond that, there are deployment
> proof points from oc-telemetry.yang that this is a desirable capability.
> >
> 
> OK. But then, I have not yet understood why the transports have to be the
> same in the model. (Which does not preclude that an implementation has a
> deviation that requires the multiple receivers of a subscription to use the
> same transport. And all this is only becoming an issue if an implementation
> does actually support multiple transports.)

Before IETF 100, transports were allowed to vary by receiver.   At the time, there seemed reasonable reasons to do this.   However previous attempts to see if there were actual use cases for such flexibility ended up with nobody chiming in.
https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html
This is one of the reasons I didn't have an issue when the WG voted to simplify things by configuring the transport at the higher level of the subscription.

So if nothing else,  there is still implementation simplicity as the transport will only be populated once across the entire subscription.

Eric

/js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>