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

[Kent Watsen <[e-mail]>]

Regarding my " the [not mandatory?] 'encoding' leaves comment, I see now 
that the "encoding" leaf has the following "when" statement:

    when 'not(../transport) or derived-from(../transport,
      "sn:configurable-encoding")';

But this doesn't negate the need for the leaf to be mandatory, for those
transports deriving from sn:configurable-encoding.

Additionally, I note that the "encoding" leaf is an identityref to base
type "encoding", from which two identities are derived *in the SN draft*
for (encode-xml and encode-json).  That these identities are defined in
the SN document surprises me, I would've thought that each notif draft
would define its own derived "encoding" identity types, if needed.  Sure,
RESTCONF is special, and other notif drafts can still define their own,
but I'd rather see this done for all transports, including RESTCONF.


Of course, these points are only relevant if we keep the "encoding" leaf...


Kent // contributor

 


===== original message =====

[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


_______________________________________________
Netconf mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=bqquEUx-vl7noz7TkXXktSCMP5kLDcq4vNfdjGgi6R8&s=iTOeSctIdaKeqG28BJIl9yub8ktRUTUPRjRqjIXlgHY&e=