[Netconf] YANG Doctor question: empty mandatory choice? (was RE: YangPush now)

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

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

   +      }  "



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