Re: [netconf] A case for vendors to move to RESTCONF?

[Kent Watsen <[e-mail]>]

Hi Med,

> Could you say some more about what happened?   Is this a case when NETCONF was better than RESTCONF?
> [Med] Both NETCONF and RESTCONF were considered at the time, but went with RESTCONF which is really better for what we wanted to achieve. Some had some concerns even with RESTCONF, e.g., https://mailarchive.ietf.org/arch/msg/dots/gqiRudRypBWhXT_10JDgvnN9Q44/. Because we also manipulated CoAP with CBOR/YANG mapping (RFC9132), we found for example CoAP better than RESTCONF on the specific point I mentioned because once could supply an URI path with one key (cuid, e.g.), while it is not possible to supply an empty key per the following from 8040:
>  
>    o  Missing key values are not allowed, so two consecutive commas are
>       interpreted as a comma, followed by a zero-length string, followed
>       by a comma.  For example, "list1=foo,,baz" would be interpreted as
>       a list named "list1" with three key values, and the second key
>       value is a zero-length string.
>  
> My hidden comment is that we need to keep in mind what is possible with target protocols to adjust some model structures (during design) to ease support of intended operations.

Interesting history and, to the Subject line of this thread, I think Gilbert makes my point.

FWIW, the optional-key issue is tracked here: https://github.com/netmod-wg/yang-next/issues/62.   As such, I believe that it is more a YANG-limitation than a RESTCONF-limitation.  It is unlikely that NETCONF would’ve helped.  That CoAP allowed a missing-key sounds like it may not be fully YANG-compliant.

Kent