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

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 26 July 2018 19:22 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 AF2B3130EB0; Thu, 26 Jul 2018 12:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 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_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 7kIgWRKWyLC8; Thu, 26 Jul 2018 12:22:43 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01042130E6F; Thu, 26 Jul 2018 12:22:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24520; q=dns/txt; s=iport; t=1532632963; x=1533842563; h=from:to:cc:subject:date:message-id:mime-version; bh=IAM7ltTGs9ke8cQqtEhWQnp8OWl/7DCjDVPixbJqC5I=; b=lOBWm4uOn4kIK51UqR7GWa0LT2oRPnpZvUAxkNut0D6CdX32f3ufFTQs 6DTTYRcVB0c/okMr/uoW/j8oMIGR8zqqOgkKBFI6c6nNJEXStPilS0UdN 40T+u2Sqv13tNbq+QNFqImve2PA62Jz12h7ceEYiAKkgP4WRXcbqrHHNF s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAQCGHlpb/5RdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJXd2N/KAqDdJRBggyVToF6CyOEA0YZgmEhNRcBAgEBAgE?= =?us-ascii?q?BAm0cDIU2AQEEJApMBQ0BFgcQHQIEMCYBBAENDRODBoEbXAgPsTaBLoo/BYk?= =?us-ascii?q?CF4FBP4ERhi0CAYE/AQGDH4I1IAKMYo0ZCQKPK44LkgwCERSBJB4BNoFScBU?= =?us-ascii?q?7gmmCTYhIhT5vAYxfgR+BGwEB?=
X-IronPort-AV: E=Sophos;i="5.51,406,1526342400"; d="scan'208,217";a="148218880"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2018 19:22:42 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w6QJMfK5027212 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Jul 2018 19:22:42 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 15:22:41 -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 15:22:41 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kwatsen@juniper.net>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
CC: "netconf@ietf.org" <netconf@ietf.org>, Andy Bierman <andy@yumaworks.com>
Thread-Topic: YANG Doctor question: empty mandatory choice? (was RE: [Netconf] YangPush now)
Thread-Index: AdQlFf9xkZm2JtfEQpiUkPoxrfRlrA==
Date: Thu, 26 Jul 2018 19:22:40 +0000
Message-ID: <727ae35abd394a85812168615acce2d3@XCH-RTP-013.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: multipart/alternative; boundary="_000_727ae35abd394a85812168615acce2d3XCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/zSkrjIdCHGLy9KkDPqgyztbU9S0>
Subject: [Netconf] 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 19:22:46 -0000

Hi YANG doctors,



We are trying to close on some YANG push drafts.  There is one YANG related question I would like to bounce off of you before making a suggested change.



In the thread:

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

is the following request:



> From: Kent Watsen, July 26, 2018 1:48 PM

>

> <chair hat on>

> ...

>

> Assuming no objections, to close the issues discussed in Montreal, we're waiting

> for the following updates:

>

>   ...

>   sub-notif: modify config model to mandate a transport



What I believe Kent is asking for is that the ietf-subscribed-notifications.yang model should be enhanced to mandate that transport specific call home parameters are augmented under the container “receivers”.  He wants to do this by incorporating a mandatory choice, with no cases being identified.  Cases would be added via augmentations in subsequent drafts.



Specifically, Kent's proposal as per

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

is "to make the augmentation of a "notif" model mandatory (see the '+' lines below), to ensure that there is always something more than just a name being configured per receiver.



      container receivers {

        list receiver {

          key "name";

          min-elements 1;

          leaf name {

            type string;

          }

   +      choice transport {

   +        mandatory true;

   +        description

   +          "Defines the transport-specific configuration data

   +           for the selected transport.";

   +      }  "



At this point there is an open question from Andy on this approach.

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



Andy’s says:

“The notion of an empty mandatory choice really stretches the definition of YANG Conformance. This says you cannot possible implement the SN module without some other module augmenting it. Yet there is no way in YANG (besides import) to say the module bar needs to be present if module foo is present.”



My first question to you is would you object to mandatory choice statements without corresponding case statements?  If you *do* have an issue with an empty mandatory choice, we should likely stay with the current solution.



If you see no issue with an empty mandatory choice, I have a second question for you.    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.



Would the YANG doctors have any issue with the structure Kent suggests above?  If no, would the YANG doctors then mandate that integrity checks per performed across the receiver case instances under a subscription?   And if mandated, how might XPATH be encoded considering transport cases are only added via augmentation?



Thanks,

Eric