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

[Andy Bierman <[e-mail]>]

On Mon, Apr 22, 2024 at 3:23 PM Kent Watsen <[e-mail]> wrote:

>
> Very interesting talk.
> I do not agree that YANG was a mistake, but no argument about the scarcity
> of tools.
> Network Tool Automation is complicated and high-level operations are
> complicated.
> It will probably never be as general-purpose as gRPC.
>
>
> I also don’t think YANG was a mistake.  In fact, coming off of SMI-ng, it
> had many things figured out.  Note that it has been very successful and, in
> fact, OC wouldn’t be anywhere without it.  Also note that the talk fails to
> say why or what’s better.  I am familiar with several data modeling
> languages and YANG is by far the best, AFAICT.
>
>
YANG extensions are not perfect, but much better than comments for use by
automation tools.
There are many details that make it work well as a replacement for MIBs and
CLI.



>
> YANG allows the server developer to implement to the YANG model and not
> the protocol.
> The clients can pick and choose between several northbound protocols.
> Each protocol defines how to map YANG statements to protocol messages.
> It will never be one-size-fits-all.
>
>
> My decoder-ring translates: servers can support many YANG-driven
> protocols, enabling clients to choose the one they like most, using
> whatever metrics makes sense to them.  Yes?
>
>
Use the right tool for the job.
IMO there is no need to worry about which protocol SHOULD be used.

Okay, fine, but I wish the dial would move from “servers can” to “servers
> should”.  But also my point is that RESTCONF is quite good, and that
> NETCONF only wins because it is entrenched.
>
>
Actually, CLI is entrenched.  ;-)

IMO it is better to stick to "YANG API" mechanisms and not rely on
protocol-specific mechanisms like in RESTCONF.
That means using POST /restconf/operations/some-rpc (or action) instead of
some other HTTP method.
This sort of extra work does not help deployment.

If the model sticks to the YANG API, then any protocol (NETCONF, RESTCONF,
CORECONF, UDP-NOTIF, etc) can be used.
There is no special work needed to add modules to the client or server.



>
> Andy
>
>
> K.
>
>
Andy