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

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

Hi Robert,

> From: Robert Wilton, July 27, 2018 7:12 AM
> 
> Hi Eric,
> 
> Perhaps you don't need the transport leaf directly under the subscription.
> 
> One option would be for the standard to state:
>   - Implementations MUST support multiple receivers with the same
> transport, and MAY support receivers with different transports.
> 
> A YANG "multiple-transports" feature could be defined to indicate that the
> device support receivers with multiple transports (so that the client can
> determine what is allowed).
> 
> If the device didn't implement the multiple-transports feature then this
> could probably be enforced with an must statement under each particular
> transports, although I'm not convinced that this really matters.

I am sympathetic to the possibilities.  There are some very cool modeling variants here.  Still, per the original thread "YangPush now", a current business objective is to see if we can conclude something with current drafts/scope.  As a single transport was the chosen consensus at and after IETF 100, going down this path would reopen some scoping discussions.   Note: for historical reasons, the discussion can be listened to at:
https://www.ietf.org/audio/ietf100/ietf100-collyer-20171116-1550.mp3
(Note: that starting at 57 minutes, you and others voice a preference for 'single' due to simplicity ;-).  Also in the recording, you can year me recognize Martin's unvarying position that encoding and transport be both the subscription level, or both be at the receiver level.  I.e., I don't see how this gets reopened, and we close soon.)

So stepping back, do you have any thoughts on whether the empty mandatory choice proposal is acceptable from the perspective of the YANG doctors?  I am good with either decision.

Thanks,
Eric

> Thanks,
> Rob
> 
> 
> On 27/07/2018 00:35, Eric Voit (evoit) wrote:
> > 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/>
> > _______________________________________________
> > yang-doctors mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/yang-doctors