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

["Eric Voit (evoit)" <[e-mail]>]

> From: Kent Watsen, July 31, 2018 8:01 PM
> 
> 
> >> 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.
> >
> > RESTCONF uses SSE for notification delivery. What you have in mind is
> > likely the HTTP/2 push transport defined in
> > draft-ietf-netconf-restconf-notif
> 
> Not really.  The thought extends beyond the notifications work.  In general,
> servers are able to be tuned as to which protocols, algorithms, etc. are
> supported.  For instance, NGINX has a parameter for if HTTP2 is enabled.
> Similarly, it seems that a server may be configured, for local policy reasons, to
> support just xml or just json.  The idea is that, if we add these tuning params to
> the ietf-restconf-[client|server] models, then those tuning params might be
> used to enable the encoding selection for *configured* restconf-notif
> subscriptions. Just an idea.
> Really, this is an open restconf-client-server draft issue, and only a restconf-
> notif draft issue when we do the bis on that draft.
> 
> 
> 
> > which I think should not be called
> > RESTCONF just because it uses some version of HTTP.
> 
> Agreed.  The "restconf-notif" draft should really only speak about the
> RESTCONF protocol.

The current RESTCONF-notif draft includes dynamic and configured subscriptions.    The draft likely should be split, one for dynamic (RESTCONF) and configured (HTTP2).   

>  That the YANG module in the draft is called "ietf-http-
> subscribed-notifications" surprises me.

The augmentations in the model are only relevant for configured, so HTTP seemed more applicable.
 
> Actually, the names of the YANG "notif" modules in general seem less than
> ideal.  I appreciate that RFC 6470 took the name "ietf-netconf-notifications",
> and these drafts are trying to follow that naming convention, but maybe we
> should choose a more concise pattern like ietf-notifications-<transport>:
> 
>   ietf-notifications-netconf
>   ietf-notifications-restconf
>   ietf-notifications-coap
>   ietf-notifications-http2

This works for me.
 
> or maybe ietf-notifications-<transport>[-<encoding>]:
> 
>   ietf-notifications-netconf
>   ietf-notifications-restconf-xml
>   ietf-notifications-restconf-json
>   ietf-notifications-coap
>   ietf-notifications-http2-xml
>   ietf-notifications-http2-json

I think creating different identities for XML & JSON encodings which are themselves dependent on a  specific transport would be confusing.

Eric

> > /js
> 
> Kent // contributor
> 
>