On Mon, Jun 29, 2015 at 03:22:55PM +0200, Ladislav Lhotka wrote:
> 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.
This is one possible explanation. I am fine if this is spelled out
clearly so that readers understand how the words are used.
> 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.
Yes, not an extension in the strict sense but still a rather standard
extension of basic types. I would find ietf-yang-* nice to list all
"basic" yang modules but then I am not religious about it either
(ietf-yang-annotation would be a concrete proposal).
> > <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.
Again, I prefer to pick a less controversial example. One can of
course debate whether 'type' and 'select' (this is what
get-filter-element-attributes defines) are generic annotations.
I would not think so.
> > 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.
I do not understand the last paragraph. Anyway, for me, the fact that
it is difficult to define "harmless" seems to underpin the need for
discussion. It is not even clear to me whether a generic NETCONF
client is required to preserve any attributes it receives. For
annotations that are purely maintained by the NC server (e.g. the
timestamp of the last modification), this is not an issue. For
anything that is client provided, this is not at all clear and if an
annotation changes server behaviour or the interpretation of the data,
this clearly requires some sort of agreement that both endpoints know
what they are doing.
> > 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.
If so, there needs to be a way to reliably obtain the information
which annotations are actually supported.
> > - 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.
I did not find the two bullets clear enough. The second bullet says:
2. Namespaces of metadata annotations are encoded in the same way as
namespaces of YANG data node instances, see
[I-D.ietf-netmod-yang-json].
This leaves it up for interpretation whether this means just the
syntax or whether this also refers to the rules when namespaces must
be included. The first bullet did not help me to understand this
either, hence I asked the question. I love to have more explicit text,
perhaps even an example (if I have two annotations 'a' and 'b' defined
in one module and another annotation 'c' defined in a second module
together with a leaf 'd', what are the possible namespace combinations
I will get if I reorder the annotations?).
/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
