Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
But don't get mw wrong, syntactically annotations would be allowed everywhere although in some places they may be a no-op. OK This is also valid, see sec. 7.7.6 in RFC 6020: snip/ I see, thanks. True, I'd rather we can find a solution for annotating XML lists. Until then, the draft SHOULD explicitly call it out as not supported. Maybe put in into an OPEN ISSUES section? But that means XML clients would be unable to receive some information. Is it what we want? I agree that is not what we want. Do you have any ideas other than using a processing instruction inside an XML comment? Thanks, Kent (as a contributor) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Kent Watsen kwat...@juniper.net writes:
Maybe I don't understand your response, but if we agree that annotations
are a server-level thing (not module-specific), then I do not agree
that a
module's description should be able to say that an annotation should be
ignored in other modules.
It depends on the annotation's semantics, and it may be designed to do
something only for certain node instances (such as leafs with union
type), or for nodes in a given namespace etc. Do you think it may be a
problem?
Those kinds of uses are fine, as they are not module-specific. I just
want to ensure we don't ever wind up with module-specific
annotations
A single namespace is essentially the same as a single module, isn't it?
But don't get mw wrong, syntactically annotations would be allowed
everywhere although in some places they may be a no-op.
I see, but then this make the example misleading. I thought it was
trying
to show how to place an annotation on the list as a whole. I see now
it says list instance, but this seems uninteresting example, as list
I will use list entry because the term instance in not defined in
YANG.
instances are just nodes for which how to apply annotations is already
known - there's nothing special about the node being a list element -
right?
Do you suggest to remove the second example in that section? But you
also wanted to add an example on anydata that is arguable even more
alike to a container.
Yes, an example for each item discussed (including anydata) is desired.
What I'm questioning here is why we need to discuss annotating list
entries at all, since they seem to follow normal rules. If true, I
recommend removing a special section for list entries/instances entirely.
I don't understand. There is no special section for list entries/instances, this
is included in the section 4.2.2 (Adding Annotations to Anydata,
Container and List Instances). I agree an example should be included for
each data node type, i.e. container, list and anydata.
As for the list example, I think it is also important to show that some
entries may be decorated with annotations while other aren't.
An annotation cannot be attached to a list as a whole? - that seems
fundamentally broken, though I understand why you say it cannot be
easily
represented in XML (via attributes). Should we consider alternative
representations?
I agree it might be useful, and I was thinking about it but I haven't
found any good way for encoding it in XML, also because in XML list
entries can be interspersed with other elements.
Interspersed with other elements? - I don't understand. For instance,
assuming:
container foobars {
list foo {
...
}
list bar {
}
}
The XML would be:
foobars
foo.../foo
foo.../foo
foo.../foo
bar.../bar
bar.../bar
bar.../bar
/foobars
Where is the interspersion?
This is also valid, see sec. 7.7.6 in RFC 6020:
foobars
foo.../foo
bar.../bar
foo.../foo
bar.../bar
bar.../bar
foo.../foo
/foobars
As for how to place annotations on an XML list as a whole, I was thinking
we could use a fake first element. For instance, the following shows an
annotation on the bar list:
foobars
foo.../foo
foo.../foo
foo.../foo
bar color=red/ // colors entire list red (notice empty
element)
bar.../bar
bar.../bar
bar.../bar
/foobars
But this is most likely illegal since it's not a valid instance
document.
This would mess up all standard XML tools.
So then maybe we could use an XML comment like this:
foobars
foo.../foo
foo.../foo
foo.../foo
!-- annotation: bar color=red --
bar.../bar
bar.../bar
bar.../bar
/foobars
A processing instruction would be slightly better but yes, it's ugly.
Ugh, this isn't great either. Anybody else have an idea?
That said, if unavoidable, the draft needs to call that out as a
limitation somewhere, because it wan't clear to me. Are there other
limitations that are not also not being called out?
Well, one could e.g. think about structured annotations but this is
again not exactly easy with XML attributes. I don't think though we can
really call it limitations - after all, the motivation for this document
was to officialize the use of XML attributes, so it would be a bit
weird to to make it incompatible with them.
True, I'd rather we can find a solution for annotating XML lists. Until
then, the draft SHOULD explicitly call it out as not supported. Maybe
put in into an OPEN ISSUES section?
But that means XML clients would be unable to receive some
information. Is it what we want?
Lada
Thanks,
Kent (as a contributor)
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Kent Watsen kwat...@juniper.net writes: 1. In Section 3, it says: snip/ Does this mean that the annotation A can be used by *any* module the server advertises, or just the modules that define/import annotation A? For all modules implemented by the server, no import is needed. Good, but I think the text should say this explicitly. OK. I assume that the intent is for the annotation to apply to the server as a whole, not any specific module. It might Yes. The description can also say that the annotation is ignored elsewhere. Maybe I don't understand your response, but if we agree that annotations are a server-level thing (not module-specific), then I do not agree that a module's description should be able to say that an annotation should be ignored in other modules. It depends on the annotation's semantics, and it may be designed to do something only for certain node instances (such as leafs with union type), or for nodes in a given namespace etc. Do you think it may be a problem? help enforce this if annotations can only be defined in modules that don't define any data-nodes and it is required that the server advertises this module explicitly (not via an import)... I expect this will be the normal way of defining annotations, and it could appear in the document as a guideline. I don't think though it is necessary to state it as a hard rule. OK, a SHOULD or RECOMMENDED statement would help to clarify this. OK. 3. In Section 4.2.2, adding metadata to the first entry in a list doesn't seem elegant. Can we instead create a special list element like the following? Maybe I don't understand but the idea is that a separate metadata objects can be attached to any or all entries of a list. In the example it is added only to the first entry but another metadata object could be added to the second entry as well. I see, but then this make the example misleading. I thought it was trying to show how to place an annotation on the list as a whole. I see now it says list instance, but this seems uninteresting example, as list I will use list entry because the term instance in not defined in YANG. instances are just nodes for which how to apply annotations is already known - there's nothing special about the node being a list element - right? Do you suggest to remove the second example in that section? But you also wanted to add an example on anydata that is arguable even more alike to a container. It is not possible to add an annotation to the whole list, also because this cannot be represented in XML encoding (via attributes). An annotation cannot be attached to a list as a whole? - that seems fundamentally broken, though I understand why you say it cannot be easily represented in XML (via attributes). Should we consider alternative representations? I agree it might be useful, and I was thinking about it but I haven't found any good way for encoding it in XML, also because in XML list entries can be interspersed with other elements. That said, if unavoidable, the draft needs to call that out as a limitation somewhere, because it wan't clear to me. Are there other limitations that are not also not being called out? Well, one could e.g. think about structured annotations but this is again not exactly easy with XML attributes. I don't think though we can really call it limitations - after all, the motivation for this document was to officialize the use of XML attributes, so it would be a bit weird to to make it incompatible with them. Lada Thanks, Kent (as a contributor) -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Martin Bjorklund m...@tail-f.com writes: Ladislav Lhotka lho...@nic.cz wrote: On 01 Jul 2015, at 16:25, Benoit Claise bcla...@cisco.com wrote: Hi Lada, ay - The set of annotations must be extensible in a distributed manner so as to allow for defining new annotations without running into the risk of collisions with annotations defined and used by others. What does in a distributed manner mean? It means that different parties needn't coordinate the names and use of annotations, as long as they don't choose conflicting YANG module names or namespace URIs. Ok, it was not too clear (to me) from the text. I will add text to explain what “distributed” means. Maybe call it decentralized? Yes, this looks better. Lada /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Benoit Claise bcla...@cisco.com writes: Hi Lada, - In the introduction, you mention: Typical use cases are: o Deactivating a subtree in a configuration datastore while keeping the data in place. o Complementing data model information with instance-specific data. o RPC operations may use metadata annotations for various purposes in both requests and responses. For example, the edit-config operation in the NETCONF protocol (seesection 7.2 of [RFC6241] https://tools.ietf.org/html/rfc6241#section-7.2) uses annotations in the form of XML attributes for identifying the point in the configuration and type of the operation. Don't you have any other examples than those 3? What about showing these examples with the spec. in this document? Note: I see that the first one is documented with module example-inactive Well, the backlash I received with draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there is consensus about general utility of annotations, practical definitions may be controversial. Even as example? Yes, I am afraid. I would be in favor to have at the very minimum one example. Otherwise, it's difficult to visualize how these metadata should be used. Sure, there will be at least one. I just have to select an appropriate one to demonstrate the intended use without stirring up some ghosts. Lada Regards, Benoit (as a contributor) -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Maybe I don't understand your response, but if we agree that annotations
are a server-level thing (not module-specific), then I do not agree
that a
module's description should be able to say that an annotation should be
ignored in other modules.
It depends on the annotation's semantics, and it may be designed to do
something only for certain node instances (such as leafs with union
type), or for nodes in a given namespace etc. Do you think it may be a
problem?
Those kinds of uses are fine, as they are not module-specific. I just
want to ensure we don't ever wind up with module-specific annotations
I see, but then this make the example misleading. I thought it was
trying
to show how to place an annotation on the list as a whole. I see now
it says list instance, but this seems uninteresting example, as list
I will use list entry because the term instance in not defined in
YANG.
instances are just nodes for which how to apply annotations is already
known - there's nothing special about the node being a list element -
right?
Do you suggest to remove the second example in that section? But you
also wanted to add an example on anydata that is arguable even more
alike to a container.
Yes, an example for each item discussed (including anydata) is desired.
What I'm questioning here is why we need to discuss annotating list
entries at all, since they seem to follow normal rules. If true, I
recommend removing a special section for list entries/instances entirely.
An annotation cannot be attached to a list as a whole? - that seems
fundamentally broken, though I understand why you say it cannot be
easily
represented in XML (via attributes). Should we consider alternative
representations?
I agree it might be useful, and I was thinking about it but I haven't
found any good way for encoding it in XML, also because in XML list
entries can be interspersed with other elements.
Interspersed with other elements? - I don't understand. For instance,
assuming:
container foobars {
list foo {
...
}
list bar {
}
}
The XML would be:
foobars
foo.../foo
foo.../foo
foo.../foo
bar.../bar
bar.../bar
bar.../bar
/foobars
Where is the interspersion?
As for how to place annotations on an XML list as a whole, I was thinking
we could use a fake first element. For instance, the following shows an
annotation on the bar list:
foobars
foo.../foo
foo.../foo
foo.../foo
bar color=red/ // colors entire list red (notice empty
element)
bar.../bar
bar.../bar
bar.../bar
/foobars
But this is most likely illegal since it's not a valid instance document.
So then maybe we could use an XML comment like this:
foobars
foo.../foo
foo.../foo
foo.../foo
!-- annotation: bar color=red --
bar.../bar
bar.../bar
bar.../bar
/foobars
Ugh, this isn't great either. Anybody else have an idea?
That said, if unavoidable, the draft needs to call that out as a
limitation somewhere, because it wan't clear to me. Are there other
limitations that are not also not being called out?
Well, one could e.g. think about structured annotations but this is
again not exactly easy with XML attributes. I don't think though we can
really call it limitations - after all, the motivation for this document
was to officialize the use of XML attributes, so it would be a bit
weird to to make it incompatible with them.
True, I'd rather we can find a solution for annotating XML lists. Until
then, the draft SHOULD explicitly call it out as not supported. Maybe
put in into an OPEN ISSUES section?
Thanks,
Kent (as a contributor)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Hi Kent,
thanks for reviewing the document.
Kent Watsen kwat...@juniper.net writes:
[As an individual contributor]
Already many comments have been made, hopefully he below comments are new:
1. In Section 3, it says:
By advertising a YANG module in which metadata annotation A is
defined using the md:annotation statement, a server specifies
support for the syntax of annotation A. This means that
configuration or state data, RPC messages and notifications will be
considered syntactically valid if annotation A is attached to any
data node instance, provided that all rules stated in this document
are observed.
Does this mean that the annotation A can be used by *any* module
the server advertises, or just the modules that define/import
annotation A?
For all modules implemented by the server, no import is needed.
For example, could a YANG module be defined like this:
module example-color-text {
namespace http://example.org/example-color-text;;
prefix rgb;
import ietf-yang-metadata { prefix md; }
description
Text is black, unless colored otherwise;
md:annotation color {
type enumeration {
enum red;
enum green;
enum blue;
}
description
This annotation only makes sense within this module.
Application of this annotation to any data node
Recursively applies to all its descendent nodes.;
}
container document {
list paragraph {
list sentence {
leaf-list word {
type string;
}
}
}
}
}
I assume that the intent is for the annotation to apply to
the server as a whole, not any specific module. It might
Yes. The description can also say that the annotation is ignored
elsewhere.
help enforce this if annotations can only be defined in
modules that don't define any data-nodes and it is required
that the server advertises this module explicitly (not via
an import)...
I expect this will be the normal way of defining annotations, and it
could appear in the document as a guideline. I don't think though it is
necessary to state it as a hard rule.
2. Also in Section 3, s/conditional:/conditional;/
OK.
3. In Section 4.2.2, adding metadata to the first entry in a list doesn't
seem elegant. Can we instead create a special list element like the
following?
Maybe I don't understand but the idea is that a separate metadata objects
can be attached to any or all entries of a list. In the example it is
added only to the first entry but another metadata object could be added
to the second entry as well.
It is not possible to add an annotation to the whole list, also because
this cannot be represented in XML encoding (via attributes).
seq: [
{
@: {
example-inactive:inactive: true
}
},
{
name: two,
...
}
]
I don't think that '@' is a valid identifier string, so it's
syntactically OK, right?
Right.
4. Also in Section 4.2.2, an anydata example would complete this section...
5. In Section 4.2.3, an anyxml example would complete this section...
OK, will add these examples.
Thanks, Lada
Thanks,
Kent
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On 01 Jul 2015, at 16:25, Benoit Claise bcla...@cisco.com wrote: Hi Lada, ay - The set of annotations must be extensible in a distributed manner so as to allow for defining new annotations without running into the risk of collisions with annotations defined and used by others. What does in a distributed manner mean? It means that different parties needn't coordinate the names and use of annotations, as long as they don't choose conflicting YANG module names or namespace URIs. Ok, it was not too clear (to me) from the text. I will add text to explain what “distributed” means. - In the introduction, you mention: Typical use cases are: o Deactivating a subtree in a configuration datastore while keeping the data in place. o Complementing data model information with instance-specific data. o RPC operations may use metadata annotations for various purposes in both requests and responses. For example, the edit-config operation in the NETCONF protocol (seesection 7.2 of [RFC6241] https://tools.ietf.org/html/rfc6241#section-7.2) uses annotations in the form of XML attributes for identifying the point in the configuration and type of the operation. Don't you have any other examples than those 3? What about showing these examples with the spec. in this document? Note: I see that the first one is documented with module example-inactive Well, the backlash I received with draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there is consensus about general utility of annotations, practical definitions may be controversial. Even as example? Yes, I am afraid. Lada I could add the annotations from the above draft as examples here but I fear they could still make for unnecessary discussions. Martin already pointed out in his review that it may be wiser to replace the inactive annotation with something less controversial. ok. Regards, Benoit -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On Wed, Jul 1, 2015 at 7:41 AM, Benoit Claise bcla...@cisco.com wrote: Hi Lada, - In the introduction, you mention: Typical use cases are: o Deactivating a subtree in a configuration datastore while keeping the data in place. o Complementing data model information with instance-specific data. o RPC operations may use metadata annotations for various purposes in both requests and responses. For example, the edit-config operation in the NETCONF protocol (seesection 7.2 of [RFC6241] https://tools.ietf.org/html/rfc6241#section-7.2) uses annotations in the form of XML attributes for identifying the point in the configuration and type of the operation. Don't you have any other examples than those 3? What about showing these examples with the spec. in this document? Note: I see that the first one is documented with module example-inactive Well, the backlash I received with draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there is consensus about general utility of annotations, practical definitions may be controversial. Even as example? Yes, I am afraid. I would be in favor to have at the very minimum one example. Otherwise, it's difficult to visualize how these metadata should be used. We support an attribute called owner which is basically the I2RS client-id. At ;least one solution proposal for I2RS is going to allow retrieval of the metadata from the ephemeral datastore (e.g., client-id, secondary-id). Perhaps an example like this will not be controversial. Regards, Benoit (as a contributor) Andy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
1. In Section 3, it says: snip/ Does this mean that the annotation A can be used by *any* module the server advertises, or just the modules that define/import annotation A? For all modules implemented by the server, no import is needed. Good, but I think the text should say this explicitly. I assume that the intent is for the annotation to apply to the server as a whole, not any specific module. It might Yes. The description can also say that the annotation is ignored elsewhere. Maybe I don't understand your response, but if we agree that annotations are a server-level thing (not module-specific), then I do not agree that a module's description should be able to say that an annotation should be ignored in other modules. help enforce this if annotations can only be defined in modules that don't define any data-nodes and it is required that the server advertises this module explicitly (not via an import)... I expect this will be the normal way of defining annotations, and it could appear in the document as a guideline. I don't think though it is necessary to state it as a hard rule. OK, a SHOULD or RECOMMENDED statement would help to clarify this. 3. In Section 4.2.2, adding metadata to the first entry in a list doesn't seem elegant. Can we instead create a special list element like the following? Maybe I don't understand but the idea is that a separate metadata objects can be attached to any or all entries of a list. In the example it is added only to the first entry but another metadata object could be added to the second entry as well. I see, but then this make the example misleading. I thought it was trying to show how to place an annotation on the list as a whole. I see now it says list instance, but this seems uninteresting example, as list instances are just nodes for which how to apply annotations is already known - there's nothing special about the node being a list element - right? It is not possible to add an annotation to the whole list, also because this cannot be represented in XML encoding (via attributes). An annotation cannot be attached to a list as a whole? - that seems fundamentally broken, though I understand why you say it cannot be easily represented in XML (via attributes). Should we consider alternative representations? That said, if unavoidable, the draft needs to call that out as a limitation somewhere, because it wan't clear to me. Are there other limitations that are not also not being called out? Thanks, Kent (as a contributor) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Ladislav Lhotka lho...@nic.cz wrote: On 01 Jul 2015, at 16:25, Benoit Claise bcla...@cisco.com wrote: Hi Lada, ay - The set of annotations must be extensible in a distributed manner so as to allow for defining new annotations without running into the risk of collisions with annotations defined and used by others. What does in a distributed manner mean? It means that different parties needn't coordinate the names and use of annotations, as long as they don't choose conflicting YANG module names or namespace URIs. Ok, it was not too clear (to me) from the text. I will add text to explain what “distributed” means. Maybe call it decentralized? /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Hi Benoit, Benoit Claise bcla...@cisco.com writes: Dear all, As a contributor, I browsed through draft-ietf-netmod-yang-metadata Thanks. ay - The set of annotations must be extensible in a distributed manner so as to allow for defining new annotations without running into the risk of collisions with annotations defined and used by others. What does in a distributed manner mean? It means that different parties needn't coordinate the names and use of annotations, as long as they don't choose conflicting YANG module names or namespace URIs. - In the introduction, you mention: Typical use cases are: o Deactivating a subtree in a configuration datastore while keeping the data in place. o Complementing data model information with instance-specific data. o RPC operations may use metadata annotations for various purposes in both requests and responses. For example, the edit-config operation in the NETCONF protocol (seesection 7.2 of [RFC6241] https://tools.ietf.org/html/rfc6241#section-7.2) uses annotations in the form of XML attributes for identifying the point in the configuration and type of the operation. Don't you have any other examples than those 3? What about showing these examples with the spec. in this document? Note: I see that the first one is documented with module example-inactive Well, the backlash I received with draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there is consensus about general utility of annotations, practical definitions may be controversial. I could add the annotations from the above draft as examples here but I fear they could still make for unnecessary discussions. Martin already pointed out in his review that it may be wiser to replace the inactive annotation with something less controversial. - Please correct the IANA considerations as in RFC7277, in particular the Registrant Contact: This document registers a URI in the IETF XML Registry [RFC3688 https://tools.ietf.org/html/rfc3688]. Following the format inRFC 3688 https://tools.ietf.org/html/rfc3688, the following registration has been made. URI: urn:ietf:params:xml:ns:yang:ietf-ip Registrant Contact: The NETMOD WG of the IETF. XML: N/A; the requested URI is an XML namespace. OK, will do. Thanks, Lada Regards, Benoit All, Today is the cutoff date for the Last Call for this draft, but the author indicated that comments received today or tomorrow can be incorporated into the draft-update being worked on. So, if you have any lingering reviews, please send them before as soon as possible. Thanks! Kent From: Kent Watsen kwat...@juniper.net mailto:kwat...@juniper.net Date: Monday, June 15, 2015 at 6:49 PM To: netmod@ietf.org mailto:netmod@ietf.org netmod@ietf.org mailto:netmod@ietf.org Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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. We are not only interested in receiving defect reports, we are equally interested in statements of the form: I have reviewed I-D XYZ and I found no issues I have implemented the data model in I-D XYZ I am implementing the data model in I-D XYZ I am considering to implement the data model in I-D XYZ This is the first Last Call for this document. Kent, as NETMOD co-chair ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Hi Alex, Alexander Clemm (alex) a...@cisco.com writes: Hi Lada, FWIW, I have a few general question/comment on the draft, for which it might be useful to add clarification: - The general approach appears to be that metadata generally needs to be defined as part of the module, and when it is, must be supported. How about augmenting an existing model with metadata Unfortunately, no. Annotations are defined via YANG extensions that may be certainly ignored by the client, and perhaps even by the server - see my earlier mail https://mailarchive.ietf.org/arch/msg/netmod/TyObJv62iwRvfXgb1Lm-YGIwfP4 It would help somewhat to have annotation as a built-in statement though not completely. after the fact (i.e. after the original definition)? This appears to be potentially a more common usage in practice. It would be useful to comment on expected usage, and perhaps add an example in which an existing model is augmented with metadata (or at least allude to the fact that this is a possibility). Annotations are orthogonal to the normal YANG stuff. If they are defined, and their use negotiated between the server and client, then they can be used anywhere. In practice, an annotation may be designed, e.g., for certain type(s) of data nodes, but from the YANG point of view they aren't a new data node type, as attributes in XML. That's why annotations are always defined at the top level of a module. So, by design, annotations are not intended to augment a specific target node. - How does metadata show up in regular operations - how is it modified and retrieved; how is it being populated? I think it would The server or client can simply add them to NETCONF or RESTCONF payload, using the encoding specified in the draft. also be helpful to add a section that illustrates usage of metadata. I was surprised to e.g. not see default as a substatement; is this something that should be added? Given that annotations are not defined for specific locations in the schema, defaults are not needed. Lada --- Alex From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen Sent: Monday, June 29, 2015 6:14 AM To: netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) All, Today is the cutoff date for the Last Call for this draft, but the author indicated that comments received today or tomorrow can be incorporated into the draft-update being worked on. So, if you have any lingering reviews, please send them before as soon as possible. Thanks! Kent From: Kent Watsen kwat...@juniper.netmailto:kwat...@juniper.net Date: Monday, June 15, 2015 at 6:49 PM To: netmod@ietf.orgmailto:netmod@ietf.org netmod@ietf.orgmailto:netmod@ietf.org Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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. We are not only interested in receiving defect reports, we are equally interested in statements of the form: I have reviewed I-D XYZ and I found no issues I have implemented the data model in I-D XYZ I am implementing the data model in I-D XYZ I am considering to implement the data model in I-D XYZ This is the first Last Call for this document. Kent, as NETMOD co-chair -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
[As an individual contributor]
Already many comments have been made, hopefully he below comments are new:
1. In Section 3, it says:
By advertising a YANG module in which metadata annotation A is
defined using the md:annotation statement, a server specifies
support for the syntax of annotation A. This means that
configuration or state data, RPC messages and notifications will be
considered syntactically valid if annotation A is attached to any
data node instance, provided that all rules stated in this document
are observed.
Does this mean that the annotation A can be used by *any* module
the server advertises, or just the modules that define/import
annotation A?
For example, could a YANG module be defined like this:
module example-color-text {
namespace http://example.org/example-color-text;;
prefix rgb;
import ietf-yang-metadata { prefix md; }
description
Text is black, unless colored otherwise;
md:annotation color {
type enumeration {
enum red;
enum green;
enum blue;
}
description
This annotation only makes sense within this module.
Application of this annotation to any data node
Recursively applies to all its descendent nodes.;
}
container document {
list paragraph {
list sentence {
leaf-list word {
type string;
}
}
}
}
}
I assume that the intent is for the annotation to apply to
the server as a whole, not any specific module. It might
help enforce this if annotations can only be defined in
modules that don't define any data-nodes and it is required
that the server advertises this module explicitly (not via
an import)...
2. Also in Section 3, s/conditional:/conditional;/
3. In Section 4.2.2, adding metadata to the first entry in a list doesn't
seem elegant. Can we instead create a special list element like the
following?
seq: [
{
@: {
example-inactive:inactive: true
}
},
{
name: two,
...
}
]
I don't think that '@' is a valid identifier string, so it's
syntactically OK, right?
4. Also in Section 4.2.2, an anydata example would complete this section...
5. In Section 4.2.3, an anyxml example would complete this section...
Thanks,
Kent
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
All, Today is the cutoff date for the Last Call for this draft, but the author indicated that comments received today or tomorrow can be incorporated into the draft-update being worked on. So, if you have any lingering reviews, please send them before as soon as possible. Thanks! Kent From: Kent Watsen kwat...@juniper.netmailto:kwat...@juniper.net Date: Monday, June 15, 2015 at 6:49 PM To: netmod@ietf.orgmailto:netmod@ietf.org netmod@ietf.orgmailto:netmod@ietf.org Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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. We are not only interested in receiving defect reports, we are equally interested in statements of the form: I have reviewed I-D XYZ and I found no issues I have implemented the data model in I-D XYZ I am implementing the data model in I-D XYZ I am considering to implement the data model in I-D XYZ This is the first Last Call for this document. Kent, as NETMOD co-chair ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Dear all, As a contributor, I browsed through draft-ietf-netmod-yang-metadata - The set of annotations must be extensible in a distributed manner so as to allow for defining new annotations without running into the risk of collisions with annotations defined and used by others. What does in a distributed manner mean? - In the introduction, you mention: Typical use cases are: o Deactivating a subtree in a configuration datastore while keeping the data in place. o Complementing data model information with instance-specific data. o RPC operations may use metadata annotations for various purposes in both requests and responses. For example, the edit-config operation in the NETCONF protocol (seesection 7.2 of [RFC6241] https://tools.ietf.org/html/rfc6241#section-7.2) uses annotations in the form of XML attributes for identifying the point in the configuration and type of the operation. Don't you have any other examples than those 3? What about showing these examples with the spec. in this document? Note: I see that the first one is documented with module example-inactive - Please correct the IANA considerations as in RFC7277, in particular the Registrant Contact: This document registers a URI in the IETF XML Registry [RFC3688 https://tools.ietf.org/html/rfc3688]. Following the format inRFC 3688 https://tools.ietf.org/html/rfc3688, the following registration has been made. URI: urn:ietf:params:xml:ns:yang:ietf-ip Registrant Contact: The NETMOD WG of the IETF. XML: N/A; the requested URI is an XML namespace. Regards, Benoit All, Today is the cutoff date for the Last Call for this draft, but the author indicated that comments received today or tomorrow can be incorporated into the draft-update being worked on. So, if you have any lingering reviews, please send them before as soon as possible. Thanks! Kent From: Kent Watsen kwat...@juniper.net mailto:kwat...@juniper.net Date: Monday, June 15, 2015 at 6:49 PM To: netmod@ietf.org mailto:netmod@ietf.org netmod@ietf.org mailto:netmod@ietf.org Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29) 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. We are not only interested in receiving defect reports, we are equally interested in statements of the form: I have reviewed I-D XYZ and I found no issues I have implemented the data model in I-D XYZ I am implementing the data model in I-D XYZ I am considering to implement the data model in I-D XYZ This is the first Last Call for this document. Kent, as NETMOD co-chair ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On Mon, Jun 15, 2015 at 10:49:32PM +, 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
On 17 Jun 2015, at 13:51, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Wed, Jun 17, 2015 at 01:41:56PM +0200, Ladislav Lhotka wrote: Well, but it is exactly what Kent objected against. It is the requirement to support “old clients” that causes the trouble here (and elsewhere). If client A sets “inactive” somewhere, then the datastore semantics will change also for client B that doesn’t understand “inactive” and may be wondering why the server ignores his edits. I understand (although RFC 6241 doesn’t say it explicitly) that, unlike YANG extensions, a NETCONF capability advertised by the server can be mandatory for the client in the sense that it has to understand and honour it. There is no way for a client to tell whether a certain capability URI (it has never seen before) is mandatory to understand or not. In fact, So it means that, e.g. the annotations from https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 cannot be safely used by the server even after advertising them via :conditional-enablement capability. I would say in a proper solution it would be the server would have to close the connection if it finds a client that does not understand its language. And yes, we are on very slippery grounds here. If implementors can create arbitrary cool 'annotations' that break clients that do not understand them, we will loose interoperability. A conclusion of this may be that it makes no sense to define annotations through YANG extension after all. On the other hand, I do see a value of having annotations defined in YANG modules. Without further protocol support to negotiate annotations, I think annotations must be limited to things that can be safely ignored by a client. I have not read the I-D yet but I would expect that it should say something like that. ;-) But it’s not a specific problem of this draft, it would simply mean that annotations that cannot be ignored cannot be used at all, no matter what. However, some annotations that have been proposed (and probably used in the wild) are of that sort. 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Ladislav Lhotka lho...@nic.cz wrote: On 17 Jun 2015, at 12:12, Martin Bjorklund m...@tail-f.com wrote: Ladislav Lhotka lho...@nic.cz wrote: Hi Martin, thanks for the review. Martin Bjorklund m...@tail-f.com writes: o Last paragraph of section 3 and the description in the extension. The text says that semantics are defined by other means. I think the semantics should be defined in the description/reference statements (by using links or inline text doesn't matter). Kent argued that an extension definition in YANG cannot make an annotation part of the contract between the server and client: the client can ignore it, and so the fact that the extension is defined in a module advertised by the server isn't sufficient for the server to start using the annotation and expect the client to take it into account. Agreed. Hence by other means, which can be, e.g. a capability. Take the inactive thing as an example. I would assume that by advertising the module where inactive is advertised, the server announces that it implements the syntax *and semantics* of this new annotation. I do not expect one capability for the syntax, and another for the semantics. Well, but it is exactly what Kent objected against. It is the requirement to support “old clients” that causes the trouble here (and elsewhere). If client A sets “inactive” somewhere, then the datastore semantics will change also for client B that doesn’t understand “inactive” and may be wondering why the server ignores his edits. Absolutely! I understand (although RFC 6241 doesn’t say it explicitly) that, unlike YANG extensions, a NETCONF capability advertised by the server can be mandatory for the client in the sense that it has to understand and honour it. No! My point is that how this affects the client must be considered case-by-case. In our implementation we support inactive, but the server sends the attribute only if the client explcitly asks for it (with-inactivetrue/with-inactive, similar to with-default). A conclusion of this may be that it makes no sense to define annotations through YANG extension after all. No I think this is the right way to do it. /martin On the other hand, I do see a value of having annotations defined in YANG modules. Lada (I also note that your requirement lists: 2. Syntax and semantics of annotations must be documented and the documentation must be easily accessible. ) But I also don't want this document to go into all details of how different annotations can be used; this needs to be carefully designed for each annotation. I suggest something like this: OLD: By advertising a YANG module in which metadata annotation A is defined using the md:annotation statement, a server specifies support for the syntax of annotation A. This means that configuration or state data, RPC messages and notifications will be considered syntactically valid if annotation A is attached to any data node instance, provided that all rules stated in this document are observed. However, the semantics of an annotation, usage rules, and expected behavior of clients and servers MUST be specified separately by other means that are outside the scope of this document. NEW: By advertising a YANG module in which metadata annotation A is defined using the md:annotation statement, a server specifies support for the syntax and semantics of annotation A. This means that configuration or state data, RPC messages and notifications will be considered syntactically valid if annotation A is attached to any data node instance, provided that all rules stated in this document are observed. and OLD: A server announces syntactic support for a particular annotation by including the module in which the annotation is defined among the advertised YANG modules (e.g., in NETCONF hello message). Semantics and usage rules for an annotation MUST be specified separately. The 'description' and/or 'reference' statements SHOULD provide corresponding links. NEW: A server announces support for a particular annotation by including the module in which the annotation is defined among the advertised YANG modules (e.g., in NETCONF hello message). /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Hi Martin,
thanks for the review.
Martin Bjorklund m...@tail-f.com writes:
Hi,
I have reviewed this document, and here are my comments. I have some
technical issues; apart from that I think this document is ready
for publication.
I have also implemented this statement in pyang (see the branch
'yang-metadata' in pyang's github).
Technical issues:
o The 'type' statement is optional in 'md:annotation', and if it is
not present, the type defaults to string. I think this is bad
design:
I followed the example of RELAX NG where type of attributes needn't be
specified - as opposed to elements.
- it is not consistent with how 'type' is used in other
YANG statements (leaf, leaf-list, typedef).
- it is not as clear for the reader as having an explicit
type.
- it saves just a few characters in every annotation (and
annotations will be rare) so it is not worth it.
I suggest making 'type' mandatory in 'md:annotation'.
OK, I am not against making it mandatory, if it is the consensus.
o The type of the argument to 'md:annotation' is not specified. It
should be an identifier (as defined in 6020bis).
Yes, I will add it to the description of the extension statement.
o Last paragraph of section 3 and the description in the
extension.
The text says that semantics are defined by other means. I
think the semantics should be defined in the
description/reference statements (by using links or inline text
doesn't matter).
Kent argued that an extension definition in YANG cannot make an
annotation part of the contract between the server and client: the
client can ignore it, and so the fact that the extension is defined in a
module advertised by the server isn't sufficient for the server to start
using the annotation and expect the client to take it into
account. Hence by other means, which can be, e.g. a capability.
Editorial issues:
o You may want to change the inactive example to something less
controversial. For example:
Yes, I've also realized this. I just thought it might be good to show an
example with a non-string type and haven't got a better idea yet.
module example-comment {
namespace http://example.org/example-comment;;
prefix ein;
import ietf-yang-metadata {
prefix md;
}
md:annotation comment {
type string;
description
This annotation is used to attach a free-form comment to
any data node.;
}
}
o Update the copyright year to 2015.
OK.
Thanks, Lada
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
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. We are not only interested in receiving defect reports, we are equally interested in statements of the form: I have reviewed I-D XYZ and I found no issues I have implemented the data model in I-D XYZ I am implementing the data model in I-D XYZ I am considering to implement the data model in I-D XYZ This is the first Last Call for this document. Kent, as NETMOD co-chair ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
