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

On Tue, Jul 31, 2018 at 12:02 PM, Alexander Clemm <
alexander.clemm@huawei.com> wrote:

> 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.
>
>
+1, except IMO there are many higher priority work items than a -bis to
this not-even-released draft.


> --- Alex
>

Andy


>
> > -----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
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>