On Mon, Jun 15, 2015 at 10:49:32PM +0000, Kent Watsen wrote:
> 
> This is a notice to start a NETMOD WG last call for the document "Defining 
> and Using Metadata with YANG":
> 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-01
> 
> Please indicate your support by Monday June 29, 2015 at 9PM EST.

Hi,

I have reviewed draft-ietf-netmod-yang-metadata-01 and I have a couple
of comments.

- I would prefer if the terminology would be streamlined. Currently,
  the I-D sometimes uses "metadata", sometimes "annotation", sometimes
  "metadata annotation". If these terms all mean the same, then I
  suggest we settle on a single term. Furthermore, the YANG statement
  'annotation' is defined in the module 'ietf-metadata'. I am not sure
  whether there is a specific reasoning behind this.

- In order to group YANG modules together that define YANG extensions
  and nothing else, does it make sense to call them 'ietf-yang-<xxx>'?

- I am having problems with the examples presented in the
  Introduction.  The 'deactivating a subtree' annotation requires a
  negotiation mechanism to be robust. The usage of attributes in the
  <edit-config> is more a protocol specification detail. Do you
  suggest that annotations would be used to define them? If so, how?

  I think there needs to be text in section 1 that distinsuishes
  between annotations that are harmless (because they can be ignored)
  and annotations that require annotation negotiation in order to be
  used.

- Why is the type statement optional for annotations? This seems to be
  inconsistent with the YANG rules.

- The definition of 'inactive' on page 6 is kind of confusing. The
  text says the presence of the annotation deactives a data node.
  If so, why is the type of the annotation a boolean?

- The text about advertisements is not clear. I think a server
  advertising annotation A not only commits to comply to this I-D but
  also to the semantics of the annotations A. I note that there is no
  mechanism to scope annotations - a server either support annotations
  for all data models it implements or none. Is this correct?
  Furthermore, if a module M defines annotation A and it contains also
  other definitions, then I can't implement M without implementing A
  system wide? That is, it is advisable to define annotations in their
  own separate modules in order to preserve flexibility, no?

- Does the presence of an annotation impact the JSON encoding rules
  that control when a module name prefix is needed or not? I assume
  the answer is 'no' but it is not clear from the text.

- s/whose the/whose/

- bump the copyright year to 2015

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to