Re: [netconf] [core] some comments on netconf-adaptive-subscription

On Thu, Jun 24, 2021 at 12:15 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> I read:
>         Title           : Adaptive Subscription to YANG Notification
>         Filename        : draft-wang-netconf-adaptive-subscription-05.txt
>
> today.  I understand the need for some kind of way to switch between
> some kind of periodic capture of value vs a edge-triggered/on-change
> process.
>
> I'm a bit surprised that the example-wifi-mac module had to be created in
> the
> appendix to provide an example.  Surely we should already have likely
> modules that are really being used and need this kind of thing.
> So one recommendation is that the document focus on already published YANG
> models that could benefit from this kind of subscription.
> (Perhaps the wifi-mac module is something that also needs to exist, and
> does
> not.  I will note that CHIP/MATTER has some kind of WIFI statistics module,
> but it's not presently written up in YANG)
>
> I had to back to RFC8641, which I don't know well at all, to be sure I
> understood the xpath criteria.  I guess I don't understand how RFC8641 and
> this document can be used for non-XML serialized YANG interactions.
>
> If bandwidth is at a premium, wouldn't you want to use
> draft-ietf-core-comi-11
> (YANG in CBOR) rather than XML?
> At which point, the obvious interaction with RFC7641 would need to be
> explained?
>
>

Commenting only on the use of CORECONF, not this draft...
IMO CORECONF is for constrained devices, possibly on constrained networks.
But if only the network is constrained, then perhaps only CBOR is really
needed.

E.g., Use RESTCONF and support "application/yang-data+cbor" in the Accept
and Content-Type headers.
Expect developers to use this media type in creative ways ;-)

It seems that the netconf (RESTCONF) and CORECONF groups should spend some
> more time together.
>

I first raised these issues in NETCONF WG in 2013
https://datatracker.ietf.org/doc/html/draft-bierman-netconf-efficiency-extensions-00

There was not then (or is now) much interest in minimizing resources used
by NETCONF.
The WG rejected other efforts as well
https://datatracker.ietf.org/doc/html/draft-mahesh-netconf-binary-encoding-00

IMO the WG missed the point of this draft, which was to preserve the
massive and expensive
investment in the NETCONF application layer already deployed. Just optimize
the network traffic
and not rewrite any feature code.

Andy

> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>