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

[[e-mail]]

Re-,

Please see inline.

Cheers,
Med

De : Kent Watsen <[e-mail]>
Envoyé : mardi 23 avril 2024 15:24
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; Jon Shallow ([e-mail]) <[e-mail]>; kaname nishizuka ([e-mail]) <[e-mail]>
Objet : Re: [netconf] A case for vendors to move to RESTCONF?


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.

 You mention “suffering” an "8040 limitation", is there a RESTCONF-next issue that needs to be tracked?

Also, could you add the missing "error-app-tag” registry issue to the netconf-next issue tracker?  - TY!

Kent



On Apr 23, 2024, at 7:12 AM, [e-mail]<mailto:[e-mail]> wrote:

Hi Kent, all,

One tangential issue when using of RESTCONF is that some operations may not be easily provided with some YANG models. For example, we used to have in early days of DOTS Data Channel (RFC8783) a YANG modules which indexes some entries using two keys but when mapping it to the DOTS operations it wasn’t possible to retrieve, e.g., all filtering entries for a given dots-clients, etc. to accommodate that, we adjusted the YANG model structure so that we don’t “suffer” from the 8040 limitation. We got it right because we have the implementation work in // of the spec.

Also, unlike conventional RESTONF, we needed a feature to detect infinite loops (yes, because we have proxies). We defined an error-app-tag, but at my surprise at the time there is no registry to track such things, so we simply included it in the spec itself.

==
   *  If it detects that its own information is present in the Via
      header field, the DOTS gateway MUST NOT forward the DOTS message.
      Messages that cannot be forwarded because of a loop SHOULD be
      logged with a "508 Loop Detected" status-line returned to the DOTS
      peer.  The structure of the reported error is depicted in
      Figure 3.

      error-app-tag:  loop-detected
      error-tag:      operation-failed
      error-type:     transport, application
      error-info:     <via-header> : A copy of the Via header field when
                      the loop was detected.
      Description:    An infinite loop has been detected when forwarding
                      a requests via a proxy.

                        Figure 3: Loop Detected Error
==

I let Jon and Kaname share their experience with RESTOCNF client implementations/integration.

Cheers,
Med

De : netconf <[e-mail]<mailto:[e-mail]>> De la part de Kent Watsen
Envoyé : lundi 22 avril 2024 18:58
À : [e-mail]<mailto:[e-mail]>
Objet : [netconf] A case for vendors to move to RESTCONF?

At NANOG 90, Rob Shakir used his Keynote in part to make a point that there are not that many NETCONF clients:  https://youtu.be/uOWxogW5Ubg?t=1721

This a true, as NETCONF is purpose specific.   On the other hand, RESTCONF is just HTTP, and one can easily argue that there are many more HTTP clients than gRPC clients.

If NETCONF client proliferation is being held up as the poster-child for the impediment of deployment velocity, it seems obvious that RESTCONF (for NEs) would more than level that position.

NE vendors should support RESTCONF (with JSON encoding) on their devices, so that their devices are easier integration targets, for both application and script developers.

Kent  // an individual contributor


____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.