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

[Kent Watsen <[e-mail]>]

[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).  

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