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

[Robert Wilton <[e-mail]>]

On 02/08/2018 01:00, Andy Bierman wrote:
>
>
> On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     On 31/07/2018 21:31, Andy Bierman wrote:
>>
>>
>>     On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit)
>>     <[e-mail] <mailto:[e-mail]>> 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: [phone]  Campus Ring 1 | 28759 Bremen | Germany
>>         > Fax:   [phone]       
>>          <https://www.jacobs-university.de/
>>         <https://www.jacobs-university.de/>>
>>
>>
>>
>>
>>     _______________________________________________
>>     yang-doctors mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/yang-doctors
>>     <https://www.ietf.org/mailman/listinfo/yang-doctors>
>
>