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

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 26 July 2018 23:35 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 B732F131269; Thu, 26 Jul 2018 16:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, 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 Waojg9iCwbR0; Thu, 26 Jul 2018 16:35:06 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A3D131266; Thu, 26 Jul 2018 16:35:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3708; q=dns/txt; s=iport; t=1532648106; x=1533857706; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tX7k1qAG0H+Y5l6eHIXw5Fx3kBjS/lzrZP0ebWcubhw=; b=UbB+ApmlwnAPER2R/rWTBvso92BaSG70EjRZV7NcXWevZodnMaBHjFGC 7M0krhHM0fROaJkuKbDbRt7tOVKfNwIG5HeTcGU5s2dPGHz9Fut6cyIVY C65afl51tM6Y1lYRaoZAErVr1Wf8/k9zQgFIYxBd3CcYIsv5f0F+mrjtL Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAQC7WVpb/4ENJK1SBwMZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgyAuY38oCoN0iAaMPYIMgzuSE4F6CyOEA0YCF4JhITQ?= =?us-ascii?q?YAQIBAQIBAQJtHAyFNgEBAQECASMRRQUJAgIBCA4CBQIBAgIJHQICAhkXFQg?= =?us-ascii?q?IAgQOBQiDGYF3CA+vToEuij0FBYEGh3cXgUE/gRGDEoMbAgGBNAsBATUKJoI?= =?us-ascii?q?6gjUgAoxijRkJAo8rjguSDAIRFIEkHTiBUnAVgySCJRcRg2eEYYU+bwGMW4E?= =?us-ascii?q?fgRsBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,407,1526342400"; d="scan'208";a="429599643"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2018 23:35:05 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w6QNZ5fO028283 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Jul 2018 23:35:05 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 26 Jul 2018 19:35:04 -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; Thu, 26 Jul 2018 19:35:04 -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+L6a3bxq1aSiIzgw
Date: Thu, 26 Jul 2018 23:35:04 +0000
Message-ID: <1b58e76f527442c3a0fa34437b9f0cd4@XCH-RTP-013.cisco.com>
References: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.cisco.com> <20180726221120.bv3mtlitoqqov2zm@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180726221120.bv3mtlitoqqov2zm@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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FhgzGLEFkq5wHGpedw9yYgVXM60>
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: Thu, 26 Jul 2018 23:35:09 -0000

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