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

["Eric Voit (evoit)" <[e-mail]>]

Hi Martin,

> From: Martin Bjorklund, July 29, 2018 11:54 AM
> 
> "Eric Voit \(evoit\)" <evoit=[e-mail]> wrote:
> > 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.";
> >
> >    +      }  "
> >
> 
> In a generic model like this one, I think the construct with a mandatory choice
> is ok.

It sounds like YANG doctors don't have a technical objection to Kent's proposal of an empty mandatory choice.

>  However, I am not convinced that this is the best solution for this model;
> it depends a bit if transport is defined per receiver or per subscription.
> 
> I assume that an augmentation would be done like this:
> 
>   module ietf-netconf-subscribed-notifications {
>     ...
>     prefix nsn;
> 
>     identity netconf { ... }
> 
>     augment /subscriptions/subscription/receivers/receiver/transport {
>       when 'derived-from-or-self(../../../transport, "nsn:netconf"');
> 
>       case netconf {
>         // leafref to call-home config
>       }
>     }
>   }
> 
> ... so that *if* the client configures the mandatory "transport" leaf to
> "nsn:netconf", then it also MUST configure the corresponding netconf-specific
> params.

I agree that this is what an augmentation would look like.  (And based on the "../../../transport", this augmentation assumes that the WG sticks with it previous position that a transport stays at the subscription level).

As the proposed augmentation by itself enforces a specific set of NETCONF transport parameters are configured (in the form of the leafref when the transport is "nsn:netconf"), do you see the empty mandatory choice as providing value?   I am ok with either answer on this, I am just trying to get closure.

Eric  

> /martin
> 
> 
> >
> >
> > 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