Juergen Schoenwaelder <[email protected]> writes: > 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.
Thanks, my replies are inline. > > - 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 my interpretation, metadata is a more general term, i.e. metadata of an instance document may consist of multiple (different) annotations. That said, it should be possible to get rid of the "metadata" term, and change the module name e.g. to "ietf-annotation-extension" > > - In order to group YANG modules together that define YANG extensions > and nothing else, does it make sense to call them 'ietf-yang-<xxx>'? Such a convention, if it is agreed upon, IMO belongs to 6087bis. Moreover, ietf-yang-types doesn't fit this pattern. > > - 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 Martin already proposed using a less controversial example in his review, and I agreed. > <edit-config> is more a protocol specification detail. Do you > suggest that annotations would be used to define them? If so, how? I haven't thought about this particular use, although it probably won't be any worse than "get-filter-element-attributes" extension in the "ietf-netconf" module. > > 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. I am not sure there is a good and absolute definition of "harmless", it depends on the context. For example, if DSDL mapping ignores the extension, then no instance document containing *any* XML attributes (no matter how benign) can ever be successfully validated with the generated RELAX NG schema. I agree it is a problem but IMO it comes down to the (wrong) assumption that a client is free to cherry-pick arbitrary parts of the data model advertised by the server, without even telling the server which parts were chosen/omitted. > > - Why is the type statement optional for annotations? This seems to be > inconsistent with the YANG rules. This was also in Martin's review, and I am ready to make it mandatory. > > - 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? Yes, it should be "presence with the value of 'true'". > > - 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 I'd agree with this but see below. > mechanism to scope annotations - a server either support annotations > for all data models it implements or none. Is this correct? Yes. > 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? Not sure, it depends on what this text in 6020(bis) really means: If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 13), the entire unknown-statement MAY be ignored by the compiler. I would assume that servers also use a "YANG compiler", so the above wording may also mean that the server can ignore extensions even in modules it advertises. > > - 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. Bullet #1 in sec. 4.2 says this. > > - s/whose the/whose/ Corrected. > > - bump the copyright year to 2015 Yes, Martin already noticed this one, too. Thanks, Lada > > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
