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

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

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