Subject: [netconf] some comments on netconf-adaptive-subscription

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jun 2021 15:14:35 -0400

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?

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

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Jun 2021 17:55:51 -0700

> At which point, the obvious interaction with RFC7641 would need to be

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 ;-)

> 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

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jun 2021 21:05:18 -0400

Michael Richardson <[email-masked]> wrote:
    > 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?

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

I didn't finish my thought here.
Specifically, it seems that the CORE WG is doing a lot of stuff with CoAP
Observes and SENML and all sorts of interesting triggers.

It seems that there ought to be more common work here.
Routers are really the original Things Of Internet.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Jun 2021 10:49:14 -0400

> 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.

CoAP/CBOR/etc. work well in less-constrained devices.
ESP32 now have several megabytes of flash, almost, but not quite 640K of RAM (520K).
Meanwhile router control plane CPUs are often way beyond this today.

    > https://datatracker.ietf.org/doc/html/draft-bierman-netconf-efficiency-extensions-00
...
    > massive and expensive investment in the NETCONF application layer
    > already deployed. Just optimize the network traffic and not rewrite any
    > feature code.

I don't think it's too late, but I don't really understand the NETCONF
investment right now.  While I'm sure that each major router vendor has a
management platform like JUNOS, I've not seen it cross-vendor for real.
I also know ISPs who try stuff like JUNOS, and get frustrated and go back to CLI.
(Often without the discipline to do it well)

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Jun 2021 09:04:05 -0700

> Observes and SENML and all sorts of interesting triggers.

There have long been 2 camps in CORE WG on this -- 1 that thinks YANG data
modeling
should be used in IoT and another that thinks YANG data modeling is overkill
and not needed for IoT.  If YANG is used then SENML info is redundant.

YANG automation is about the entire tool chain, not just the bytes on the
wire,
but even if you focus just on that, I think CBOR+SID can achieve much higher
information density than SENML.

> Routers are really the original Things Of Internet.

I do not think it helps to classify a router as an IoT device.

Andy