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

[Andy Bierman <[e-mail]>]

Hi,

I would prefer to not add empty mandatory choices to any YANG module.
An empty choice is bad enough. In 2119 terms, using this container is a
SHOULD, not a MUST.


Andy


On Fri, Jul 27, 2018 at 10:37 AM, Eric Voit (evoit) <
evoit=[e-mail]> wrote:

> > From: Juergen Schoenwaelder, July 27, 2018 12:15 PM
> > To: Eric Voit (evoit) <[e-mail]>
> > Cc: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> > <[e-mail]>; [e-mail]; [e-mail]
> > Subject: Re: [yang-doctors] YANG Doctor question: empty mandatory
> > choice? (was RE: [Netconf] YangPush now)
> >
> > On Fri, Jul 27, 2018 at 03:33:05PM +0000, Eric Voit (evoit) wrote:
> > >
> > > 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.)
> > >
> >
> > Still looks like a CLR and somewhat odd once you use a choice for the
> > transports of a receiver
>  (using a choice likely was not yet proposed back
> > then).
>
> Yes, the empty mandatory choice was not proposed then.   And honestly, I
> would be absolutely fine if the empty mandatory choice is not included in
> the final model.
>
> My intent in starting this thread is that I just want to give a fair
> hearing for Kent on whether his suggestion is technically acceptable.
> While I don't see Kent's proposal as being especially pretty, it might be
> able to bring us to closure on what is perhaps the last technical issue for
> the current drafts.
>
> > Looking at the draft-ietf-netconf-subscribed-notifications-14.txt, how
> do the
> > states of a receiver work with multiple transports? It seems some text in
> > the draft kind of assumes that a receiver has a single transport. It
> seems
> > dynamic subscriptions always have just one associated transport.
> > Configured subscriptions apparently can have multiple with some
> > constraints and it is unclear how the configured subscriptions states
> work
> > with multiple transports.
>
> Figure 9 defines receiver state specific just for a single configured
> subscription from the perspective of a publisher.  It is valid to have a
> receiver handle multiple subscriptions using different transports.
>
> > I am not sure if I understand things right but it seems to me that a
> > subscription can have multiple receivers and every receiver can have
> > multiple transports. Perhaps simplifying this to 'a subscription can have
> > multiple receivers and every receiver has a single transport (like in the
> > dynamic subscription case)
>
> There is no reason a single dynamic subscriber can't have independent
> subscriptions using different transports to the same publisher.
>
> >  and there are no constraints on the type of
> > transports used by the different receivers' gives you a model that is
> less
> > complex, easier to clearly define (the state of a receiver becomes
> simpler to
> > derived from a single transport state) and the model likely still does
> > everything that is practically needed.
>
> Controllers will spin up and tear down multiple independent subscriptions
> within a single transport session.  This will be driven by applications
> sitting on controllers having different data needs.  One example of this
> would be creating a replay subscription to retrieve events dropped.   Also
> based on previous threads, there is also a need for the first configured
> subscription from a receive to initiate a separate transport session (even
> if a seemingly acceptable one is already is in place).  This avoids the
> possibility of some over-zealous dynamic subscription application from
> closing down a transport session subsequently used by a configured
> subscription.
>
> Eric
>
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>