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

From: Qin Wu <[email-masked]>
Date: Fri, 25 Jun 2021 14:31:16 +0000

-----邮件原件-----
发件人: Michael Richardson [mailto:[email-masked]] 
发送时间: 2021年6月25日 9:05
收件人: Qin Wu <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [core] some comments on netconf-adaptive-subscription

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

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.
[Qin]: data modeling language such as YANG can be common work for both CORE WG and NETCONF WG,
But they may choose different transport protocol, such as NETCONF, RESTCONF, HTTP 2.0, COAP, MQTT, COMI
Secondly, I think it will be nice to separate constrained device management from resource unconstrained network device management,
Constraint device as IoT device can be temperature sensor, current, voltage sensor which can be seen as affiliated devices pertaining to resource unstrained network device.
In data center scenarios, we do a lot of such affiliated devices or sensors such as air conditioner, water leakage alarm sensor deployed together with data center switch devices.
These IoT devices only use MQTT/COAP/HTTP to communicate with their IoT platform, for data center switch devices, you may still rely on network management protocols such as NETCONF,
SNMP, gRPC, etc.
Do you see this differently? Michael?
--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Jun 2021 12:58:18 -0400

Qin Wu <[email-masked]> wrote:
    mcr> I didn't finish my thought here.  Specifically, it seems that the CORE
    mcr> WG is doing a lot of stuff with CoAP Observes and SENML and all sorts
    mcr> of interesting triggers.

    Qin> data modeling language such as YANG can be common work for both CORE
    Qin> WG and NETCONF WG, But they may choose different transport protocol,
    Qin> such as NETCONF, RESTCONF, HTTP 2.0, COAP, MQTT, COMI Secondly, I
    Qin> think it will be nice to separate constrained device management from
    Qin> resource unconstrained network device management, Constraint device
    Qin> as IoT device can be temperature sensor, current, voltage sensor
    Qin> which can be seen as affiliated devices pertaining to resource
    Qin> unstrained network device.

temperature, current are critical values for routing equipment, aren't they?

    Qin> In data center scenarios, we do a lot of such affiliated devices or
    Qin> sensors such as air conditioner, water leakage alarm sensor deployed
    Qin> together with data center switch devices.  These IoT devices only
    Qin> use MQTT/COAP/HTTP to communicate with their IoT platform, for data
    Qin> center switch devices, you may still rely on network management
    Qin> protocols such as NETCONF, SNMP, gRPC, etc.  Do you see this
    Qin> differently? Michael?

It seems that we ought to seek convergence here.
That's what I'm saying.  That any split here is for historical reasons, and
does not make sense going forward.