[netconf] Comments on draft-claise-netconf-metadata-for-collection-02

[Balázs Lengyel <[e-mail]>]

Hello,

The draft contains good ideas, but it needs more work. Comments below.

 

General: The base drafts use the term capabilities not metadata. Unless you
have a reason for it, please stick to capabilities.

 

Ch.3

suggested-observable-period: why is this available only at implementation
time? IMHO it should be available in runtime too. I don’t understand the
description. 

“Those 5 seconds ...” What does this refer too?

 

optimized-measurement-point: How should this effect a YANG-Push subscription
? Some examples would be good.

 

corresponding-mib-oid: Wouldn’t it be easier to define a YANG extension
statement that defines this SNMP OIDs in the YANG models itself? These are
static design time values, that cannot change in run-time.

 

related-node: A relationship can be of many-many types. IMHO for this to be
usable in an interoperable manner you need to narrow down what you mean by
relationship. E.g.

config-state-node-relationship: The capability is used for YANG models that
use separate branches to specify the configuration and the state data for
management objects,  For a config=true container or list this capability
specifies the list/container that carries the state data for the same
managed object. 

 

“A generic RPC...” remove the word generic. It does not mean anything
specific.

 

“Per-node dynamic metadata includes, part of the get-measurement-metadata
RPC”
 I think you mean: 
 

 

 

optimized-measurement-point:

“up the data tree chain” change to up the containment hierarchy. The
sentence could use some rewording.

Can the node selector be any selector, or maybe it should point at a
specific schema node? Otherwise, it would be very hard to specify the
answer.

 

“computed-observable-period”: This is the same as
suggested-observable-period after it is dynamically adjusted. It serves the
same purpose. IMHO it is a general principle of ALL capabilities, that 

*	Capabilities are potentially available both in implementation time
and in run-time. However, a network node may decide that it has no useful
information in implementation time, so it does not publish a value
*	During runtime the system MAY or MAY NOT be change/update a
capability value. Just because the value may be updated dynamically it is
still the same capability.

 

“active-measurements”: Needs rewording. It is unclear what this returns, why
do you need to calculate measurement-periods to return the subscription IDs

 

Ch.4.1

According  to
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabi
lities#section-4

“Every set of such capabilities SHOULD be

   wrapped in a container under the augment statement to cleanly

   separate different groups of capabilities.  These "wrapper

   containers" SHALL be augmented in at /sysc:system-capabilities and

   /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per-node-

   capabilities.””

Please follow it.

 

grouping system-node-metadata-info: this is a very generic name, that says
nothing about what capabilities are contained in the grouping. Find a better
name. Generally the base draft uses the term capability not metadata.

 

minimum-observable-period: I would call this either
measurement-update-period or granularity (widely used by other SDOs) This
really states the update period of the counter. The fact that there is no
real sense in observing it more frequently is just a consequence.

 

suggested-observable-period: “only available at implementation time” Why? Do
you hide the value that was available in implementation-time? If yes why? If
this is part of the YANG model it should be available in run-time. I propose
to remove this half-sentence.

 

related-node: description should be improved. In case of an NMDA server with
a non-NMDA model (e.g. ietf-system) this could still be useful.

 

get-measurement-metadata: 

The input node selector MAY point to multiple nodes if some key values are
missing. This is not handled.

“RPC that returns the optimized” – what does optimized mean in this case?
Avoid the word, describe instead what you mean.

“This RPC  is added to allow clients to learn dynamically changing
metadata” – You could learn dynamic metadata(? Use capabilities)  with a
simple <get> an RPC is not needed. State the real purpose. 

I would rather call the rpc something like: get-per-node-metadata

Why is this rpc only valid for measurement metadata? It could be useful for
any capability.

What if there are multiple optimized-measurement-points above the input
node? Specify.

Why are minimum-observable-period, corresponding-mib-oid and  related-node
not returned. Illogical.

 

list active-measurements: What is a “measurement” in this context? Is it the
YangPush subscription for the counter? If yes return a subscriptionId. 

Or did you mean the smallest reporting period of all YangPush subscriptions?

What is returned if there are on-change Yang-Push subscriptions for the
counter (or whatever data node)?

 

get-system-node-capabilities

The difference between the 2 RPCs is not clear.

The input node selector MAY point to multiple nodes if some key values are
missing. Is this intentional?

Why is this rpc only valid for measurement metadata? It could be useful for
any capability.

“If the input node is not leaf/leaf-list then metadata of its subtree nodes
is returned.” The metadata/capabilities can be very different for different
schema nodes in the subtree. Will you return a separate set of capabilities
for every child node? That could be long!

 

Output: Node should be a key

node-selector-capability: the name is wrong. This is a list of capabilities
not a new node-selector-capability.

Regards Balazs

 

-- 

Balazs Lengyel                    Senior Specialist
Ericsson Hungary Ltd. 

Mobile: [phone]              email: [e-mail]