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

[Martin Bjorklund <[e-mail]>]

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



/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