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

[Qin Wu <[e-mail]>]

Thanks Michael for valuable comments, see reply inline below.
-----邮件原件-----
发件人: Michael Richardson [mailto:[e-mail]] 
发送时间: 2021年6月25日 3:15
收件人: Qin Wu <[e-mail]>; [e-mail]
抄送: [e-mail]
主题: some comments on netconf-adaptive-subscription


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

[Qin]: That's a good suggestion, WiFi provides a good use case for this adaptive subscription mechanism. we did try some existing published YANG models, but it seems YANG models size is too big.
That's why we create simplified Wifi mac example Module. If you can provide a link to CHIP/MATTER WIFI statistics module, we are happy to quote that existing module.

>(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.
[Qin]: RFC8641 is built on top of RFC8639, RFC8639 Subscribe Notification module allow you specify encoding, take RESTCONF as an example, you can specify any encoding you like.

>If bandwidth is at a premium, wouldn't you want to use draft-ietf-core-comi-11 (YANG in CBOR) rather than XML?
[Qin]: The intention is to optimize the existing YANG push mechanism for NETCONF/RESTCONF and other management protocols. And the network device can support multiple capture periodic intervals, the mechanism we introduce is to allow the network device switch to different capture periodic interval automatically without asking the NMS for permission each time. I hope this clarifies.
>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.

[Qin]: I am also hoping RESTCONF and CORECONF can work together, but they seems to look into different use cases (constrained device management vs unconstrained device management) .
I am not sure we should generalized RESTCONF and CORECONF into a single protocol.
My understanding they have a different basis, for CORECONF, the basis is COMI, should it be extended to support pub sub?, there is one relevant draft, i.e.,
Draft-birkholdz-yang-core-telemetry, 
RFC7641 have different basis, which is coap, it seems introduce similar pub sub mechanism, but I confused this work with draft-ietf-core-coap-pubsub. So what about other IoT protocol such as MQTT? It also support pub sub mechanism.
I think we should not mix coap with comi, otherwise, we will see a lot of mess and confusion. Am I right?

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






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