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

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

From: Andy Bierman, July 31, 2018 4:32 PM

On Tue, Jul 31, 2018 at 12:39 PM, Eric Voit (evoit) <[e-mail]<mailto:[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 prefer the MUST be in the description-stmt for the choice,
instead of "mandatory true". (I prefer SHOULD but if the WG wants MUST)

<Eric> Do you see value in having the choice exposed?   Or if it is a SHOULD, is the mechanism below sufficient?

I am really ok with either, I just want to close.

Eric


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