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

Robert Wilton <rwilton@cisco.com> Thu, 02 August 2018 10:39 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 E74C4130E0F; Thu, 2 Aug 2018 03:39:46 -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 f1akfO3EfrgN; Thu, 2 Aug 2018 03:39:43 -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 C5EDB130DFA; Thu, 2 Aug 2018 03:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26316; q=dns/txt; s=iport; t=1533206382; x=1534415982; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=4K/MlFp3ysenDTCuPJpPPa+DT9fK/7GEuUx1HfM9HBg=; b=QtB96u/8j08c7VVKEJNfvFp2a4ZnTqyycOrGFNxUInXW0sAHLgZnp43D 7V+08uu081FQ6P5XWGRcZRbigW3n39MSH4Hq/kyUqGfboGWMA9YInO8Qq b9wt50SJH8sXWvjwB0/Hj6i7yDpzXMYJT2gwI5YXG4Pkq6HpuFQiGlZux c=;
X-IronPort-AV: E=Sophos;i="5.51,435,1526342400"; d="scan'208,217";a="5519398"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2018 10:39: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-3.cisco.com (8.15.2/8.15.2) with ESMTP id w72Ade6T003048; Thu, 2 Aug 2018 10:39:40 GMT
To: Andy Bierman <andy@yumaworks.com>
Cc: "Eric Voit (evoit)" <evoit@cisco.com>, "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> <05ee68cd-ccc0-6803-6c71-b3952ee5608d@cisco.com> <CABCOCHQn6aVV6iEL8pCUAf1QGNQM=1GNEtyX9iTV03Cm1tpivQ@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <ce907eec-8bc0-2b04-0ad4-15a7eb54673f@cisco.com>
Date: Thu, 2 Aug 2018 11:39:40 +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: <CABCOCHQn6aVV6iEL8pCUAf1QGNQM=1GNEtyX9iTV03Cm1tpivQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------62BC7301CDC660240564367D"
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-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/TaxXBRRBF4i2zpaeOPdKmzptIGs>
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 10:39:47 -0000


On 02/08/2018 01:00, Andy Bierman wrote:
>
>
> On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton <rwilton@cisco.com 
> <mailto:rwilton@cisco.com>> wrote:
>
>
>
>     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.
>
>
>
> It really is not OK, and has never been OK, which is why I think the 
> next version of YANG
> should try to get this right.
>
> As a client developer, I want to know the contract in advance, without 
> any missing clauses.
> With a self-contained module (only internal + augment + uses) the 
> entire contract is clear
> (at least module names are specified, maybe not revisions on imports 
>  (Ver DT will fix that)
>
> A mandatory choice depending on 100% external augments is not 
> self-contained.
> It is not a complete contract.
>
> IMO, the way to fix it is to expand the conformance for YANG modules 
> so that packages
> could be specified, or perhaps virtual external dependencies. YANG 
> catalog says what a vendor
> does implement. YANG Conformance says what a vendor is supposed to 
> implement.
> The client developer needs to know both.
So, this is moving away from Eric's issue.

Yes, I agree that we need to define something like packages.

Although I can partly see conformance at being at the module level, I'm 
not convinced that is most useful.  Instead, once you consider 
deviations and data node lifecycles, then I think that it is more 
helpful to consider conformance at the schema (and per data-node) level.

In the case of schema, I mean the combination of (a set of implemented 
module revisions (including deviations), import-only module revisions, 
supported features, supported datastores).  I.e. the information that is 
being exposed via YANG libary(-bis).

So, for a client to check whether a device will accept its 
configuration, it constructs a schema of all data nodes it is 
configuring/accessing, along with their types and constraints, and then 
compares every data node in the schema against the schema supported by 
the device (yes, I agree that the schema should be available up front 
rather than only via YANG library, which is similar to Balazs's draft 
relating to YANG instance data).

I anticipate that your reaction might be to say that this sounds very 
complicated, but at the end of the day, I think that this is probably 
the simplest robust way of ensuring compatibility, once you take 
deviations, versioning, features all into account.

Thanks,
Rob


>
>
> Andy
>
>     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 <mailto:yang-doctors@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/yang-doctors
>>     <https://www.ietf.org/mailman/listinfo/yang-doctors>
>
>