Re: [netconf] Comments on draft-tao-netconf-data-export-capabilities

[Qin Wu <[e-mail]>]

Hi, Balazs:
发件人: netconf [mailto:[e-mail]] 代表 Balázs Lengyel
发送时间: 2021年7月31日 18:05
收件人: [e-mail]
主题: [netconf] Comments on draft-tao-netconf-data-export-capabilities-0

Hello,
“Capability values on a smaller, more specific part of the
server's data always override more generic values.”

This not following the latest version of draft-ietf-netconf-notification-capabilities. Please check the description of module ietf-system-capabilities.



[Qin Wu] Thanks for correction, you are right, this statement is not applicable here any more and should be taken out. We will make yang push related server capability described in this draft align with the latest version of I-D.netconf-notification-capabilities.



2.1 tree diagram:

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities#section-4 states:

Every set of such capabilities SHOULD be

   wrapped in a container under the augment statement to cleanly

   separate different groups of capabilities.

This is not followed in your augment of /sysc:system-capabilities

[Qin Wu] Agree to follow the rule defined in I-D.netconf-notification-capabilities, to do so, we have two choice

add data-export-export-capabilities container on top of data-export-capabilities list;

change data-export-capabilities list into data-export-capabilities container and in addition, change all the leaf under data-export-capabilities list into leaf list to support e.g., multiple transport, encoding support.

My preference is the option b.



https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities#section-4.2 states:

1) search for a datastore-capabilities list entry for

     the specific datastore. When stating a specific capability, the

     relative path for any specific capability must be the same

     under the system-capabilities container and under the

     per-node-capabilities list: the same grouping for defining

     the capabilities MUST be used.

Please follow that. Please specify every capability both on the under system-capabilities and under per-node-capabilities.

A specific capability might always be defined on system or datastore or per-node level on your system, other systems might have a more granular capability set. Even if a capability is available on e.g. per-node level, your system is free not to use it.

[Qin Wu] Agree to add per-node level capabilities.

Why is this model valid only for telemetry? It should be usable for other notifications too. E.g. transport-protocol or security is just as relevant for any other notification.

[Qin Wu] Yes, telemetry is the key use case. But I agree it is applicable other notification, will make this clear in the next version.

What is event based subscription mode?

[Qin Wu] Timer-event-support is similar to what is described in period subscription, i.e., push update is triggered periodically, the timer will be set to the update interval defined in RFC8641. I feel this parameter is a little bit redundant, I think we can take it out.

What is coutner based trigger mode ?

[Qin Wu] Counter threshold support is applicable to a set of data nodes which are integer built-in type.  The data node value are restricted not to exceed the specific threshold value. But not all the data nodes need to have such counter threshold support since not all of data nodes are integer built-in type. Even data nodes are integer built-in type, it is not mandatory to support threshold constraints, be default, this feature can be disabled.

Does this parameter make sense to you?



suppress-redundant, this mechanism is not described. What is suppressed?

[Qin Wu] Suppress-redundant indicate that duplicated data objects should be suppressed to be sent during each update interval.

The mechanism is to detect the occurrence of monitored data object in each update interval. If the occurrence is equal to or more than 2, the value of monitored data object will not be reported.


Regards Balazs

--
Balazs Lengyel                    Senior Specialist                       Ericsson Hungary Ltd.
Mobile: [phone]              email: [e-mail]<mailto:[e-mail]>