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

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> 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
> 
>