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

I am wondering why we are reopening the issue of multiple encodings/transports per receiver vs per subscription?  

Having single transport / encoding per subscription is a simpler design (feedback from implementors; simplifies dealing with any error conditions due to encoding that would affect one receiver but not others in the same subscription; Einar has explained this in the past) and, while I am in general a fan of general design, there does not seem to be business requirements and scenarios that demand this - and even if there were, this would constitute merely an optimization (since if you have different receivers who want different encodings/tranport, you can always simply create another subscription).  

If in the future there is really desire to add this as an additional feature, we can put this into a -bis version.  (Adding stuff will be easier than taking things away.)  Let's just be done.  

--- Alex

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Tuesday, July 31, 2018 7:51 AM
> To: kwatsen@juniper.net
> Cc: evoit=40cisco.com@dmarc.ietf.org; netconf@ietf.org
> Subject: Re: [Netconf] YANG Doctor question: empty mandatory choice?
> 
> Kent Watsen <kwatsen@juniper.net> wrote:
> > [removing yang-doctors list, and updating subject line accordingly]
> >
> >
> > >> > Why do all receivers of a subscription have to use the same
> transport?
> > >>
> > >> This was something that Martin and Eric worked out before we did
> > >> the first Last Call.  Eric doesn't seem to know the particular
> > >> reason, other than Martin seems to think it’s easier.
> > >
> > > No; I personally also prefer a design where each receiver has its
> > > own transport + encoding.
> >
> > +1
> >
> >
> > > The original model had a common "encoding" for all receivers, and
> > > then a receiver-specific transport - I think this is even worse,
> >
> > Agreed.
> >
> >
> > > and suggested to have transport + encoding defined together
> > > preferrably receiver-specifc or else common for all receivers.
> > >
> > > If the WG now believes that the transport + encoding should be done
> > > per receiver, this should be fairly easy to change.
> >
> > I also prefer per receiver, and I think that doing so will simplify
> > the model, as neither the mandatory "transport" nor the [not
> > mandatory?] "encoding" leaves have to be specified.
> >
> > In particular, my thoughts are that the "notif" model should provide
> > for the encoding selection, if needed (it's not needed for NETCONF, or
> > COAP I imagine).
> 
> I agree.  I think this would be a cleaner design.
> 
> 
> /martin
> 
> 
> >
> > In the case of RESTCONF, we could update the ietf-restconf-client and
> > ietf-restconf-server models to include an "encodings" leaf-list, to
> > configure the RESTCONF server which encodings it should support.  We
> > likely need to do something similar to configure which HTTP versions
> > should be supported.  Now, in a general RC server, the server could
> > support both but, if the restconf-notif draft has its own list of
> > restconf-servers (i.e., it uses the "restconf-server-grouping" itself,
> > see my July 19 email for a YANG example), then a constraint could be
> > added limiting the number "supported" to just one.  Thus, when the RC
> > server reboots, and connects to the receiver and *automatically* (no
> > client RPC) starts pushing notifications, it can know what encoding to
> > use.
> >
> > I'm still unsure if its legal for an RC server to automatically push
> > notifications without a client-initiated RPC of any sort, and I'm also
> > uncertain if supporting *configured* subscriptions for NC or RC is
> > needed (see my message July 20 email).  So, some of this may work
> > itself out as we progress.
> >
> > I know that we're not defining the *configured* notif drafts in this
> > first effort, the we are publishing the SN draft with a configuration
> > model, my only concern now is configuration model presented in the SN
> > draft.
> >
> >
> > Kent // contributor
> >
> >
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf