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

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

Hi Juergen,

> From: Juergen Schoenwaelder, July 26, 2018 6:11 PM
> To: Eric Voit (evoit) <[e-mail]>
> Cc: Kent Watsen <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: [yang-doctors] YANG Doctor question: empty mandatory
> choice? (was RE: [Netconf] YangPush now)
> 
> On Thu, Jul 26, 2018 at 07:22:40PM +0000, Eric Voit (evoit) wrote:
> 
> > 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.
> 
> Why is the transport leaf needed if the choice cases identify the transport?
> Why do all receivers of a subscription have to use the same transport?

One transport for all receivers was a voted WG decision at IETF 101.  Some of the reasons from threads like:
https://www.ietf.org/mail-archive/web/netconf/current/msg13875.html
https://www.ietf.org/mail-archive/web/netconf/current/msg14899.html 

include:
(1) Simpler YANG model
(2) Simpler implementation possible as a single configured subscription need be connected to only one transport
(3) Simpler implementation in that there is no expectation set on the publisher that there will be no transport loss if the transport type is reconfigured for a particular receiver mid-subscription.
(4) Separation of implementation/troubleshooting concerns, as only one transport is involved

Eric

 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>