Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00

[Kent Watsen <[e-mail]>]

>  - who believes a mechanism to define metadata annotations
>    should be standardized


Not yet.  

First I think we need to clear the way for attributes to be used safely.
We used attributes in <edit-config> and also with-defaults, but in both
cases the client either accepted the contract of the protocol (base:1.1)
or explicitly opted into receiving the attributes (report-all-tagged).
Specifically, what happens to a legacy client if the attribute MUST be
semantically understood (e.g., the enabled/inactive) in order to correctly
process the data?   Even if we don't care about the client, we might want
to assert that the client will always echo back any attributes it receives
on config=true nodes - this might require a base:1.2 for NETCONF, I'm not
sure how to do this for RESTCONF.  Perhaps I'm conflating what and how,
but it seems that we're skipping a step.




>  - who plans to use the proposed annotation extension statement

As proposed, I don't see how it can be used.

Specially, I'd need to see more examples around how to declare where
attributes can be used.  For instance, how to specify that the "default"
and "enabled" parameter can only appear on config=true nodes or a
"last-sampled-timesamp" can show up only on specific config=false nodes?
Or that a "timestamp" or "Etag" attribute MUST be on top-level config node
and MAY be on other config nodes (yes, I know that RESTCONF uses HTTP
headers for this, but a similar mechanic may be desired for NETCONF).

Note that as long as attributes are cross-cutting (applying to all config
nodes generically), then they'll likely only be used for "metadata".  But,
if we introduce the ability for attributes to be used on specific nodes
(top-level node, or specific config=false node), then we open the door to
attributes being used for regular data (not just metadata), which I don't
think we want...


>  - who is willing to review the document during the WG phase

I will, if it is promoted to a WG item.




Thanks,
Kent