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

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 27 July 2018 15:33 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 D1487130E74; Fri, 27 Jul 2018 08:33:10 -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=unavailable 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 I9HzH6B2ce7R; Fri, 27 Jul 2018 08:33:07 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B755C130F8A; Fri, 27 Jul 2018 08:33:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6762; q=dns/txt; s=iport; t=1532705587; x=1533915187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zs/BVFdQxq5q+XMJz0r4JTCrta1XP981UJ6dKCq/0Ns=; b=YgDudwfoxsgXlKbchds4KvmkY1YGnFGSLBH6tjX6Z+a0YUsN79ATtdv9 AuLrtP/ObOYIRBRY0wS7uwVzEG/XFfXwaHSXowY8ds5jDBAUon7sxBkQ5 uJJXtOLOuZjfHZt0JitxTRGGLEKgO+rbqhsWV3BKqMgYEgZ60PyoOTxcx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEBQB7Oltb/5RdJa1RBwMZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBg05jfygKg3SUQYIMgzuUEAsYC4QDRgIXgmQhOBQBAgE?= =?us-ascii?q?BAgEBAm0cDIU2AQEBAwEBASEROgsFCQICAQgQBQIBAgIJHQICAhkMCxUICAI?= =?us-ascii?q?EDgUIgxmBdwgPrgyBLoo+BQWBBod3F4FBP4ERgX2BFYMbAQEBgTQLAQE1Cia?= =?us-ascii?q?COoI1IAKMaI0jCQKPLI4Okg0CERSBJDQhgVJwFTuCaYIlFxGDZ4RhhT5vAY0?= =?us-ascii?q?XgR+BGwEB?=
X-IronPort-AV: E=Sophos;i="5.51,410,1526342400"; d="scan'208";a="427839083"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2018 15:33:06 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w6RFX6u8007459 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Jul 2018 15:33:06 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 11:33:05 -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 11:33:05 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>
CC: "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+L6a3bxq1aSiIzgwgAEKvQD///rvIA==
Date: Fri, 27 Jul 2018 15:33:05 +0000
Message-ID: <d88c590e29854474b3ca836c4d3c6853@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> <7a87a2c9-9af6-2555-e661-519e0352d1bf@cisco.com>
In-Reply-To: <7a87a2c9-9af6-2555-e661-519e0352d1bf@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.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/mp9HVXEn4AINuZy9Y58Vz-JMRqM>
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 15:33:11 -0000

Hi Robert,

> From: Robert Wilton, July 27, 2018 7:12 AM
> 
> Hi Eric,
> 
> Perhaps you don't need the transport leaf directly under the subscription.
> 
> One option would be for the standard to state:
>   - Implementations MUST support multiple receivers with the same
> transport, and MAY support receivers with different transports.
> 
> A YANG "multiple-transports" feature could be defined to indicate that the
> device support receivers with multiple transports (so that the client can
> determine what is allowed).
> 
> If the device didn't implement the multiple-transports feature then this
> could probably be enforced with an must statement under each particular
> transports, although I'm not convinced that this really matters.

I am sympathetic to the possibilities.  There are some very cool modeling variants here.  Still, per the original thread "YangPush now", a current business objective is to see if we can conclude something with current drafts/scope.  As a single transport was the chosen consensus at and after IETF 100, going down this path would reopen some scoping discussions.   Note: for historical reasons, the discussion can be listened to at:
https://www.ietf.org/audio/ietf100/ietf100-collyer-20171116-1550.mp3
(Note: that starting at 57 minutes, you and others voice a preference for 'single' due to simplicity ;-).  Also in the recording, you can year me recognize Martin's unvarying position that encoding and transport be both the subscription level, or both be at the receiver level.  I.e., I don't see how this gets reopened, and we close soon.)

So stepping back, do you have any thoughts on whether the empty mandatory choice proposal is acceptable from the perspective of the YANG doctors?  I am good with either decision.

Thanks,
Eric

> Thanks,
> Rob
> 
> 
> On 27/07/2018 00:35, Eric Voit (evoit) wrote:
> > Hi Juergen,
> >
> >> From: Juergen Schoenwaelder, July 26, 2018 6:11 PM
> >> To: Eric Voit (evoit) <evoit@cisco.com>
> >> Cc: Kent Watsen <kwatsen@juniper.net>et>; yang-doctors@ietf.org;
> >> netconf@ietf.org
> >> Subject: Re: [yang-doctors] YANG Doctor question: empty mandatory
> >> choice? (was RE: [Netconf] YangPush now)
> >>
> >> On Thu, Jul 26, 2018 at 07:22:40PM +0000, Eric Voit (evoit) wrote:
> >>
> >>> For all receivers in a subscription, the selected transport choice
> >>> case in Kent’s suggestion above MUST match to the value of the
> >>> “transport” leaf which is one level higher in the tree.  I.e.:
> >>>
> >>>      +--rw subscriptions
> >>>         +--rw subscription* [identifier]
> >>>            +--rw transport                                  transport {configured}?
> >>>            +--rw receivers
> >>>               +--rw receiver* [name]
> >>>               +--rw (transport)
> >>>                  +--rw :(NETCONF)
> >>>                  |  +--rw (NETCONF specific call home parameters)
> >>>                  +--rw :(HTTP2)
> >>>                      +--rw (HTTP2 specific parameters)
> >>>
> >>> (Note on the tree above, I inserted the NETCONF and HTTP2 cases of
> >>> transport for illustration purposes for the question below.  These
> >>> two cases would actually be incorporated via separate augmentations
> >>> to the ietf-subscribed-notifications.yang model.)
> >>>
> >>> Considering above, It seems difficult to enforce that the transport
> >>> cases selected under all receivers for a single subscription MUST be
> >>> identical, and also MUST match to the value of the “transport” leaf
> >>> under the subscription.
> >> Why is the transport leaf needed if the choice cases identify the
> transport?
> >> Why do all receivers of a subscription have to use the same transport?
> > 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.html
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14899.html
> >
> > 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
> >
> > 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/>
> > _______________________________________________
> > yang-doctors mailing list
> > yang-doctors@ietf.org
> > https://www.ietf.org/mailman/listinfo/yang-doctors