Juergen Schoenwaelder <[email protected]> writes:
> 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.
OK, I will try to figure out what's better.
>
>> 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).
Fine with me.
>
>> > <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'd love to hear about use cases and examples that are less
controversial but still not completely useless. Having none begs the
question of why annotations are needed at all.
>
>> > 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
The last paragraph means that there should be a mechanism for *both*
server and client to tell the other side the exact data model it is
using. The idea that a client (old or whatever) just silently picks a
subset of the server's model is IMO terribly broken.
> 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.
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.
>
> If so, there needs to be a way to reliably obtain the information
> which annotations are actually supported.
Absolutely, although it might suffice to clarify the "YANG compiler" thing.
>
>> > - 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
For annotations in JSON, the namespace ID (module name) must always be
included in their name, and annotations are essentially leaves so they
cannot participate in any "namespace switching". And bullet #1 says
encoding of other nodes is unaffected by the presence of annotations.
> 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?).
I don't understand. Do you mean reordering within a single "metadata object"?
The order of its members is irrelevant, and all members must have an
explicit namespace.
With a data model consisting of these two modules,
module foo {
...
md:annotation a;
md:annotation b;
}
module bar {
...
md:annotation c;
leaf d { type uint8; }
}
the correct JSON encoding is
{
"bar:d": 42,
"@bar:d": {
"foo:a": "xxx",
"foo:b": "yyy",
"bar:c": "zzz"
}
}
modulo member reordering, but the namespaces need to be as shown.
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/>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
