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

[Martin Bjorklund <[e-mail]>]

"Eric Voit (evoit)" <[e-mail]> wrote:
> 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).

Right, the when expression needs tweaking if the transport leaf moves.

> 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.

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?  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.


/martin



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