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

Robert Wilton <rwilton@cisco.com> Wed, 01 August 2018 16:01 UTC

Return-Path: <rwilton@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 EC87E130E44; Wed, 1 Aug 2018 09:01:44 -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 zr3SklOcJPEA; Wed, 1 Aug 2018 09:01:42 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF979130E2E; Wed, 1 Aug 2018 09:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15436; q=dns/txt; s=iport; t=1533139302; x=1534348902; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=5T/5MYJj3E7nE+R41tBel8fthXnWcJsc+GN1wnUqsKo=; b=TTBo5gGw5tWoIAx80AcSRc819gXrFHuPfUrAuTzC0RuibDhscqS3gDcU kk5SbZiRyWwlL4t8AclqT1RntVcQbLxqHpV3zcSur3wasNF3Nr5hvw5lc SB7Ujhl4RY/hclwmcalCRJqLN+5wFbsmiRDK4cDZGLRjymdGKCSOSK4AN Q=;
X-IronPort-AV: E=Sophos;i="5.51,432,1526342400"; d="scan'208,217";a="5501195"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2018 16:01:40 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w71G1dFT008733; Wed, 1 Aug 2018 16:01:40 GMT
To: Andy Bierman <andy@yumaworks.com>, "Eric Voit (evoit)" <evoit@cisco.com>
Cc: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
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>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <05ee68cd-ccc0-6803-6c71-b3952ee5608d@cisco.com>
Date: Wed, 1 Aug 2018 17:01:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CABCOCHQPYyWgXS8Y_n5PN-AEQ5myQXX5s0KvkjQnfAh4VOMbrA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------C7247EADB1E0C867CE1A1D37"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.106, dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/6v9esquy91IZJKL-07hZnGXU5AE>
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: Wed, 01 Aug 2018 16:01:45 -0000


On 31/07/2018 21:31, Andy Bierman wrote:
>
>
> On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit) <evoit@cisco.com 
> <mailto:evoit@cisco.com>> wrote:
>
>     > From: Juergen Schoenwaelder, July 31, 2018 1:48 PM
>     >
>     > On Mon, Jul 30, 2018 at 08:41:42PM +0200, Martin Bjorklund wrote:
>     > >
>     > > The empty mandatory choice does provide value since it
>     requires that
>     > > some transport-specific parameters are configured.  However,
>     can we
>     > > assume that all transports require configuration parameters here?
>     >
>     > Can you have a receiver without any transport parameters?
>     >
>     > > It is probably safest to not have a mandatory choice, and instead
>     > > ensure that each transport augements the proper params -- and
>     since
>     > > this is YANG 1.1, the transport params that are augmented can
>     actually
>     > > be marked as mandatory.
>     >
>     > Frankly, an empty mandatory choice quite clearly says "this is
>     incomplete and
>     > unusable without an augmentation".
>
>     My read above is the YANG doctor's position is that we should
>     *not* use the empty mandatory choice.  Let me know if I got this
>     wrong.
>
>
> I do not think a consensus call has been done yet, but I agree with 
> Juergen
> and already raised the point that YANG conformance does not handle a
> "MUST augment" use-case very well.
I think that "empty choice + mandatory true" it is OK from a conformance 
perspective.  The concept seems similar to an programmatic interface, 
abstract class, or even the abstract identity idea that has been 
proposed for YANG.  If a server implements the module but no augments of 
the choice then it cannot be configured because the constraint will 
always fail.  Andy, is your concern that tooling will warn that part of 
the model is unusable?

I have to say that much prefer the option of putting "mandatory: true" 
in the choice than "MUST provide an implementation" in the description 
because the former is machine readable whilst the latter is not.

However, I would also be fine not to have the "mandatory: true", but 
with the choice description to state something along the lines that the 
empty choice is to allow for augmentations of different transports, and 
configured subscriptions may not be usable unless at least one transport 
case statement is available."  But perhaps some implementation will 
provide the flexibility of defining a single transport for all 
subscriptions (if this is feasible).

One other observation that could affect the decision here is that YANG 
allows "mandatory: true" to be removed in a future revision in a 
backwards compatible way, but doesn't allow it to be added.

Thanks,
Rob


>
> I prefer the MUST be in the description-stmt for the choice,
> instead of "mandatory true". (I prefer SHOULD but if the WG wants MUST)
>
>
> Andy
>
>
>
>     That would mean that each transport document supporting configured
>     subscriptions would then augment transport specific parameters to
>     "/subscriptions/subscription/receivers/receiver".  And (assuming
>     the "single transport" decision of IETF100 isn't changed), that
>     the identity "transport" could be leveraged to enforce that only a
>     single transport specific set of credentials are associated with a
>     receiver.
>
>     A sample YANG augmentation for NETCONF would then look like:
>
>     module ietf-netconf-subscribed-notifications {
>
>       prefix nsn;
>
>       import ietf-netconf-client { prefix ncc; }
>       import ietf-subscribed-notifications { prefix sn; }
>
>       identity netconf {
>         base sn:transport;
>         base sn:inline-address;
>         description
>           "NETCONF is used as a transport for notification messages and
>            state change notifications.";
>       }
>
>       augment
>     "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
>        when 'derived-from(../../../transport, "nsn:netconf")';
>        description
>           "This augmentation allows NETCONF specific parameters to be
>           exposed for a receiver.";
>         leaf netconf-endpoint {
>           type leafref {
>             path "/ncc:netconf-client/ncc:initiate/ncc:netconf-server" +
>                     "/ncc:endpoints/ncc:endpoint/ncc:name";
>           }
>           mandatory true;
>           description
>             "Remote client which need to initiate the NETCONF
>     transport if
>             an existing NETCONF session from that client is not
>     available.";
>         }
>       }
>     }
>
>     Which results in:
>       +--rw subscriptions
>          +--rw subscription*
>             +--rw transport         transport  {configured}?
>             +--rw receivers
>                +--rw receiver*
>                   +--rw nsn:netconf-endpoint    leafref
>
>     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/
>     <https://www.jacobs-university.de/>>
>
>
>
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors