Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice?

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 02 August 2018 13:05 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 8EAC6130E39; Thu, 2 Aug 2018 06:05:17 -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, HTML_MESSAGE=0.001, 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 HlhQOQfswLNT; Thu, 2 Aug 2018 06:05:09 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9652A130E53; Thu, 2 Aug 2018 06:05:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13498; q=dns/txt; s=iport; t=1533215109; x=1534424709; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9k6jq2+EDwg111HY0/h1WWCGHuMKMFRMuWUsIzWNfVY=; b=QBBTQV+i022OurMvYd7rDguWV1OpPH43jcZMElGKJFvOfaV96P+X109l UKfFkiMkY1407KOxe3cBzCR1+BVdIXkr896vdHEEeNQTm0Ey7kyAoFzlF huI+rdMGEzGJinm3EYCXtj4uCl7gDDrS+RCGUfhHDXNjmrY2tbasQc7Ru 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAACJAGNb/5tdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJXd2N/KAqDdIgGjEKCDZBAhRqBeguEbAIXgmwhNBgBAgE?= =?us-ascii?q?BAgEBAm0ohTYBAQEDASMKTAULAgEIFSoDAgICMBQRAgQBDQUIE4MGgRtcCLE?= =?us-ascii?q?2gS6KWIkIF4FBP4ESgxKFDCgCgkmCNSACkhmIDQkCiQOGNYFRjEuIFYoNAhE?= =?us-ascii?q?UgSQdOIFScBWDJJBTb41vgRsBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,436,1526342400"; d="scan'208,217";a="151926907"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2018 13:05:08 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w72D58LB019821 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Aug 2018 13:05:08 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 2 Aug 2018 09:05:07 -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, 2 Aug 2018 09:05:07 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net>
CC: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [yang-doctors] YANG Doctor question: empty mandatory choice?
Thread-Index: AQHUJ1ReOwlfbH+3hkGPLp9Bm3apCaSn4DUwgAB+GwCAAYN0gP//xXiQgABoMwCAAUbTgIAAAjeAgAAKyYCAAB/OgIAAc1OAgAACCICAAHiS8A==
Date: Thu, 2 Aug 2018 13:05:07 +0000
Message-ID: <359c6f2db6b0451086be0651d6cbe7bd@XCH-RTP-013.cisco.com>
References: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.cisco.com> <20180729.175356.1841285666617255654.mbj@tail-f.com> <77080682bf90495caec48436453e4750@XCH-RTP-013.cisco.com> <20180730.204142.1505732335534077415.mbj@tail-f.com> <20180731174827.n5r2jebon45s2cxy@anna.jacobs.jacobs-university.de> <b8dc903dc04a46088bcca106ac45c4fc@XCH-RTP-013.cisco.com> <CABCOCHQPYyWgXS8Y_n5PN-AEQ5myQXX5s0KvkjQnfAh4VOMbrA@mail.gmail.com> <05ee68cd-ccc0-6803-6c71-b3952ee5608d@cisco.com> <CABCOCHRtg9jB0=b5bPPT3MS0QJcwgAY24Fg0RewXhPMR8Y+O0w@mail.gmail.com> <958669b9-c523-3c43-eca4-fbc255fc1bc8@cisco.com> <CABCOCHRv9VGTwkvcnQz+VZDXK=+5pp-mdxQjdRmE=kXZPSDSXQ@mail.gmail.com> <91F96417-7820-42C0-AC6F-3A21694B7A95@juniper.net> <CABCOCHTKLC8hBXLQ=55LkhVJ=0YDV1RRjmyWWCgXU+ucKt2b-Q@mail.gmail.com>
In-Reply-To: <CABCOCHTKLC8hBXLQ=55LkhVJ=0YDV1RRjmyWWCgXU+ucKt2b-Q@mail.gmail.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: multipart/alternative; boundary="_000_359c6f2db6b0451086be0651d6cbe7bdXCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.146, xch-rtp-006.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/TCnzd0wfn3jj0OXhvktm9kLldu8>
Subject: Re: [Netconf] [yang-doctors] YANG Doctor question: empty mandatory choice?
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, 02 Aug 2018 13:05:17 -0000

From: Andy Bierman, August 1, 2018 9:42 PM


On Wed, Aug 1, 2018 at 6:34 PM, Kent Watsen <kwatsen@juniper.net<mailto:kwatsen@juniper.net>> wrote:

> It just seems strange that the model designers are positive the solution belongs in a
> case-stmt inside this choice.  So positive that MUST is in order, which means harm
> to the Internet will happen if this choice is not provided, with no possibility of any
>  exception ever.

Disagree.  As Robert pointed out, the yang update rules allow mandatory true to
become mandatory false.  In my view, choosing to do the "mandatory true" now
is the conservative choice.

PS: I do not believe it is possible to have a receiver that does not define a transport.
       If that were allowed, then it would be vendor magic.



OK -- I do think it is a huge burden for a vendor to provide an augment,
even if it is just to indicate "my real transport config is over there
or it is not in YANG".

<Eric>  Instead of “augment” for now we will simply going to deviate away the “empty mandatory choice” until call home information is placed into vendor native or IETF YANG models.

That deviate approach is easier than augmentation.  And it matches what we need to do when something isn’t available in YANG anyway.

Does anyone have an issue if we try a consensus call on Kent’s proposal of “empty mandatory choice”?

Eric

Kent // contributor


Andy