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

[Andy Bierman <[e-mail]>]

On Wed, Aug 1, 2018 at 9:01 AM, Robert Wilton <[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]>
> 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?
>

That is possible.
I agree with Juergen that a mandatory empty choice clearly indicates that
the module is incomplete
and unusable on its own.  Is that a feature?

Andy


>
> 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/>
>>
>
>
>
> _______________________________________________
> yang-doctors mailing [e-mail]://www.ietf.org/mailman/listinfo/yang-doctors
>
>
>