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] three color meters in diffserv model
Hello Ferdi, We have following text in section 3 of the draft: A meter qualifies if the traffic arrival rate is based on agreed upon rate and variability. A meter is generically modeled as qualifying rate and variability defined as a token bucket. Single rate meter [RFC2697https://tools.ietf.org/html/rfc2697] can be defined as two such token buckets with first defining the rate and committed burst and excess burst for second bucket. “ I think it covers quite what you are suggesting. “Overflow” is implied by the algorithm. Regards, Aseem From: FERDINAND Pienaar pienaar.ferdin...@alcatel-sbell.com.cnmailto:pienaar.ferdin...@alcatel-sbell.com.cn Date: Tuesday, June 30, 2015 at 5:59 PM To: netmod@ietf.orgmailto:netmod@ietf.org netmod@ietf.orgmailto:netmod@ietf.org Subject: Re: [netmod] three color meters in diffserv model Hello Aseem Thanks for your answer! If I understand correctly, the absence of the leaf meter-rate has special meaning: the bucket gets tokens by overflow from another bucket. So for RFC 2697, bucket C is has rate CIR, and its fail-action next-meter-id points to bucket E. Bucket E has no leaf meter-rate, so its token increment comes from bucket C's overflow. How is it determined where a bucket's overflow goes? I'm assuming it is to the bucket pointed to by the next-meter-id in its fail-action (if the target has no rate), but this is not obvious to me -- doesn't this whole mechanism deserve a mention in the description of the meter-rate and/or fail-action? Or maybe it’s simpler than that, and token overflow is implied only for a list with two meters, one with a meter rate and the other without? Regards Ferdi -Original Message- From: Aseem Choudhary (asechoud) [mailto:asech...@cisco.com] Sent: Wednesday, July 01, 2015 04:47 To: FERDINAND Pienaar; netmod@ietf.orgmailto:netmod@ietf.org Subject: Re: [netmod] three color meters in diffserv model Hello Ferdi, Thanks for your question! Single Rate Three Color Marking can be supported by configuring two meters, one with rate and burst, second with just burst. ³Coupling flag² functionality, which is more effective in color aware mode, is not defined by any of diffserv RFC¹s, and hence not included in the current model. This functionality can be added as separate augmentation ³mef² module to base diffserv module. Regards, Aseem On 6/29/15, 9:30 PM, FERDINAND Pienaar pienaar.ferdin...@alcatel-sbell.com.cnmailto:pienaar.ferdin...@alcatel-sbell.com.cn wrote: Hello I think I see how container meter-cfg is intended to allow configuration of RFC 2697 and 2698 style meters (by linking two meters in the meter-list via the pointer next-meter-id). But it seems to me that a way to indicate overflow from one bucket to another during token update is needed. In RFC 2697, bucket E is incremented only if bucket C is full, i.e. C overflows into E. In RFC 2698, buckets C and P are updated independently. The Metro Ethernet Forum's Bandwidth Profile Algorithm explicitly supports configuring this type of coupling, via parameter CF, coupling flag. It's not clear to me how RFC 2697 can be supported by concatenating the meters in the YANG model, unless there is a way to indicate overflow between them. Ferdi Pienaar Alcatel Shanghai-Bell ___ netmod mailing list netmod@ietf.orgmailto: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-json-04 (until 2015-06-29)
On 01 Jul 2015, at 09:21, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: On 30 Jun 2015, at 15:39, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: On 30 Jun 2015, at 15:20, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: Hi Juergen, thank you for the review. Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: This is a notice to start a NETMOD WG last call for the document JSON Encoding of Data Modeled with YANG: https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 Please indicate your support by Monday June 29, 2015 at 9PM EST. Hi, I have reviewed draft-ietf-netmod-yang-json-04. - I am not sure I agree with the wording in section 3. Why is section 8.3.3 only applicable to XML encoded data? Validation applies to datastores. While constraints are defined using XML-based notations You are right that this section shouldn't talk about XML-encoded data, i.e. serialized form. On the other hand, XPath 1.0 spec says: XPath operates on the abstract, logical structure of an XML document, …. So I think a datastore needs to be represented, at least conceptually, as XML infoset. such as XPATH, how the validation is carried out is not defined in the YANG specifications. I guess I actually disagree with the I don't think this is true. YANG spec doesn't say how must and when statements are evaluated, and relies on XPath. RFC 6020: When a datastore is validated, all must constraints are conceptually evaluated once for each data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its must statements are not evaluated. [...] The text you substituted here with an ellipsis is actually quite important for this discussion because it defines the context for XPath evaluation (together with section 6.4), in particular the data tree on which every XPath expression is evaluated. It is clear that the data tree can also comprise state data, notification content or RPC input/output, i.e. not only datastore content as you keep saying. Terms like context node refer to the XPath data model as described in sec. 5 of the XPath spec: http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model (and section 6.4 in RFC 6020 says it explicitly). We need to know, at least conceptually, how to construct the XPath data tree from JSON text. For example, it has to be clear that leaf-list entries encoded as a JSON array appear as sibling nodes in the data tree, otherwise a must constraint specified for the leaf-list won't work correctly. I don't think this is anyhow evident and IMO it has to be addressed. This is the purpose of section 3 in draft-ietf-netmod-yang-json-04. Would it help if validation is replaced with XPath evaluation throughout this section? No. I continue to believe (a) a datastore is validated and not an XML infoset (or something like that) and (b) that the evaluation of must constraints is conceptual. Both NETCONF and YANG are absolutely silent about the data model of a datastore, so I assume it can be pretty much anything. Can you explain how a “must” constraint is conceptually evaluated on, say, key-value database? Lada JSON is an encoding. It remains unclear why you think that the JSON encoding has any impact of what happens with a datastore. /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-json-04 (until 2015-06-29)
On Wed, Jul 1, 2015 at 6:01 AM, Ladislav Lhotka lho...@nic.cz wrote: On 01 Jul 2015, at 14:33, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote: On 01 Jul 2015, at 09:21, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: On 30 Jun 2015, at 15:39, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: On 30 Jun 2015, at 15:20, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: Hi Juergen, thank you for the review. Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: This is a notice to start a NETMOD WG last call for the document JSON Encoding of Data Modeled with YANG: https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 Please indicate your support by Monday June 29, 2015 at 9PM EST. Hi, I have reviewed draft-ietf-netmod-yang-json-04. - I am not sure I agree with the wording in section 3. Why is section 8.3.3 only applicable to XML encoded data? Validation applies to datastores. While constraints are defined using XML-based notations You are right that this section shouldn't talk about XML-encoded data, i.e. serialized form. On the other hand, XPath 1.0 spec says: XPath operates on the abstract, logical structure of an XML document, …. So I think a datastore needs to be represented, at least conceptually, as XML infoset. such as XPATH, how the validation is carried out is not defined in the YANG specifications. I guess I actually disagree with the I don't think this is true. YANG spec doesn't say how must and when statements are evaluated, and relies on XPath. RFC 6020: When a datastore is validated, all must constraints are conceptually evaluated once for each data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its must statements are not evaluated. [...] The text you substituted here with an ellipsis is actually quite important for this discussion because it defines the context for XPath evaluation (together with section 6.4), in particular the data tree on which every XPath expression is evaluated. It is clear that the data tree can also comprise state data, notification content or RPC input/output, i.e. not only datastore content as you keep saying. Terms like context node refer to the XPath data model as described in sec. 5 of the XPath spec: http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model (and section 6.4 in RFC 6020 says it explicitly). We need to know, at least conceptually, how to construct the XPath data tree from JSON text. For example, it has to be clear that leaf-list entries encoded as a JSON array appear as sibling nodes in the data tree, otherwise a must constraint specified for the leaf-list won't work correctly. I don't think this is anyhow evident and IMO it has to be addressed. This is the purpose of section 3 in draft-ietf-netmod-yang-json-04. Would it help if validation is replaced with XPath evaluation throughout this section? No. I continue to believe (a) a datastore is validated and not an XML infoset (or something like that) and (b) that the evaluation of must constraints is conceptual. Both NETCONF and YANG are absolutely silent about the data model of a datastore, so I assume it can be pretty much anything. Can you explain how a “must” constraint is conceptually evaluated on, say, key-value database? This is a question to answer by someone who implements it on a key-value database. Note that RFC 6020 just has XML mapping sections and otherwise tells nothing about how instances of data nodes are represented in a datastore. I have thus always assumed that everything works fine because the datastore model is essentially XML Infoset, except that “data tree” is used instead of “infoset”, “data node” instead of “information item” etc. In any case, with RFC 6020 in hand I can only explain how JSON is mapped to XML. I have no idea how to get JSON data into a datastore of unknown data model (which you take for granted), and then conceptually evaluate XPath expressions on it. I feel we are wasting time and energy here. Indeed, and it is frustrating.
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On 01 Jul 2015, at 14:33, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote: On 01 Jul 2015, at 09:21, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: On 30 Jun 2015, at 15:39, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: On 30 Jun 2015, at 15:20, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: Hi Juergen, thank you for the review. Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: This is a notice to start a NETMOD WG last call for the document JSON Encoding of Data Modeled with YANG: https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 Please indicate your support by Monday June 29, 2015 at 9PM EST. Hi, I have reviewed draft-ietf-netmod-yang-json-04. - I am not sure I agree with the wording in section 3. Why is section 8.3.3 only applicable to XML encoded data? Validation applies to datastores. While constraints are defined using XML-based notations You are right that this section shouldn't talk about XML-encoded data, i.e. serialized form. On the other hand, XPath 1.0 spec says: XPath operates on the abstract, logical structure of an XML document, …. So I think a datastore needs to be represented, at least conceptually, as XML infoset. such as XPATH, how the validation is carried out is not defined in the YANG specifications. I guess I actually disagree with the I don't think this is true. YANG spec doesn't say how must and when statements are evaluated, and relies on XPath. RFC 6020: When a datastore is validated, all must constraints are conceptually evaluated once for each data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its must statements are not evaluated. [...] The text you substituted here with an ellipsis is actually quite important for this discussion because it defines the context for XPath evaluation (together with section 6.4), in particular the data tree on which every XPath expression is evaluated. It is clear that the data tree can also comprise state data, notification content or RPC input/output, i.e. not only datastore content as you keep saying. Terms like context node refer to the XPath data model as described in sec. 5 of the XPath spec: http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model (and section 6.4 in RFC 6020 says it explicitly). We need to know, at least conceptually, how to construct the XPath data tree from JSON text. For example, it has to be clear that leaf-list entries encoded as a JSON array appear as sibling nodes in the data tree, otherwise a must constraint specified for the leaf-list won't work correctly. I don't think this is anyhow evident and IMO it has to be addressed. This is the purpose of section 3 in draft-ietf-netmod-yang-json-04. Would it help if validation is replaced with XPath evaluation throughout this section? No. I continue to believe (a) a datastore is validated and not an XML infoset (or something like that) and (b) that the evaluation of must constraints is conceptual. Both NETCONF and YANG are absolutely silent about the data model of a datastore, so I assume it can be pretty much anything. Can you explain how a “must” constraint is conceptually evaluated on, say, key-value database? This is a question to answer by someone who implements it on a key-value database. Note that RFC 6020 just has XML mapping sections and otherwise tells nothing about how instances of data nodes are represented in a datastore. I have thus always assumed that everything works fine because the datastore model is essentially XML Infoset, except that “data tree” is used instead of “infoset”, “data node” instead of “information item” etc. In any case, with RFC 6020 in hand I can only explain how JSON is mapped to XML. I have no idea how to get JSON data into a datastore of unknown data model (which you take for granted), and then conceptually evaluate XPath expressions on it. I feel we are wasting time and energy here. Indeed, and it is frustrating. However, I’d like to know what to do with section 3 of the yang-json document. Lada /js -- Juergen Schoenwaelder Jacobs
Re: [netmod] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET)
Hello Susan, - Topology model which is a composite of: o Generic topology model: draft-ietf-i2rs-yang-network-topo-01https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/ o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 released later this week). o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) At this time, none of the Topology models utilize Traffic engineering. It is anticipated that these models will support traffic engineering. Reading this , my question is whether there is intention for Traffic Engineering part of topology model to exploit/coordinate with Teas , and particularly with draft-liu-teas-yang-te-topo or to proceed with distinct contributions internal to I2RS. Thanks Sergio ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)
On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote: On 01 Jul 2015, at 09:21, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: On 30 Jun 2015, at 15:39, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: On 30 Jun 2015, at 15:20, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: Hi Juergen, thank you for the review. Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote: This is a notice to start a NETMOD WG last call for the document JSON Encoding of Data Modeled with YANG: https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 Please indicate your support by Monday June 29, 2015 at 9PM EST. Hi, I have reviewed draft-ietf-netmod-yang-json-04. - I am not sure I agree with the wording in section 3. Why is section 8.3.3 only applicable to XML encoded data? Validation applies to datastores. While constraints are defined using XML-based notations You are right that this section shouldn't talk about XML-encoded data, i.e. serialized form. On the other hand, XPath 1.0 spec says: XPath operates on the abstract, logical structure of an XML document, …. So I think a datastore needs to be represented, at least conceptually, as XML infoset. such as XPATH, how the validation is carried out is not defined in the YANG specifications. I guess I actually disagree with the I don't think this is true. YANG spec doesn't say how must and when statements are evaluated, and relies on XPath. RFC 6020: When a datastore is validated, all must constraints are conceptually evaluated once for each data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its must statements are not evaluated. [...] The text you substituted here with an ellipsis is actually quite important for this discussion because it defines the context for XPath evaluation (together with section 6.4), in particular the data tree on which every XPath expression is evaluated. It is clear that the data tree can also comprise state data, notification content or RPC input/output, i.e. not only datastore content as you keep saying. Terms like context node refer to the XPath data model as described in sec. 5 of the XPath spec: http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model (and section 6.4 in RFC 6020 says it explicitly). We need to know, at least conceptually, how to construct the XPath data tree from JSON text. For example, it has to be clear that leaf-list entries encoded as a JSON array appear as sibling nodes in the data tree, otherwise a must constraint specified for the leaf-list won't work correctly. I don't think this is anyhow evident and IMO it has to be addressed. This is the purpose of section 3 in draft-ietf-netmod-yang-json-04. Would it help if validation is replaced with XPath evaluation throughout this section? No. I continue to believe (a) a datastore is validated and not an XML infoset (or something like that) and (b) that the evaluation of must constraints is conceptual. Both NETCONF and YANG are absolutely silent about the data model of a datastore, so I assume it can be pretty much anything. Can you explain how a “must” constraint is conceptually evaluated on, say, key-value database? This is a question to answer by someone who implements it on a key-value database. I feel we are wasting time and energy here. /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 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
[netmod] Initial IEEE Yang Models Committed
FYI, There was discussion of IEEE/Ethernet models a while back. I wanted to let everyone know that an initial one was just pushed. https://github.com/YangModels/yang/tree/master/experimental/ieee —Tom ___ 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] Y45-04 and ietf-yang-library
Hi,
I am going to update the draft so the conformance leaf
is an enumeration with 'implement' and 'import' enums.
The 'none' enum is not needed because the deviations are
listed inside the module entry. A module server would return
the conformance for the proxied server, not itself.
No new objects will be added.
Only item # is being addressed.
Every module the server implements with be listed once
with conformance=implement. Every module and revision
that those modules import (rippled through all imports) will be listed
in the library, with conformance=import, except of
course if the imported module is also an implemented module.
No other modules will be listed.
Andy
On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman a...@yumaworks.com wrote:
On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder
j.schoenwael...@jacobs-university.de wrote:
Writing as technical contributor...
On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote:
Hi,
Here's a short summary, and then some questions for the WG.
The ietf-yang-library module is designed to serve two purposes:
1. A protocol-independent advertisement mechanism for YANG 1.1
modules.
2. A list of the YANG modules stored in a server.
Q1. Do you agree with these goals?
I primarily care about goal 1.
Q2. Should this module be designed to work with both YANG 1.0 and
YANG 1.1 servers - i.e., should it have yang-version 1.1 or not?
If it should not be defined using YANG 1.1, why is this module
special?
I assume this module will sooner or later be YANG 1.1 anyway.
Q3. Should the /modules/module list be designed to store both YANG
1.0 and YANG 1.1 modules?
Yes. Even if YANG 1.1 hits the street tomorrow, we will not have
revised all published YANG data models that were written using YANG
1.0. So a server needs to be able to announce both YANG 1.0 and YANG
1.1 modules.
Yes -- We also agreed that we would not be republishing modules
just to change the yang-version to 1.1.
There are lots of YANG modules in progress at this time.
Perhaps 3 out of 100 are relying on YANG 1.1 statements.
It seems rather disruptive to declare all module must be YANG 1.1
since it has not even made it through WGLC yat, let alone
be published as an RFC, let alone be implemented
in real tool-chains.
I suspect if people find out the only think YANG 1.1 in their module
(preventing their existing tools from working) is a yang-version-stmt,
they might not be too happy.
Andy
Q4. Consider these modules, which both import foo without revision:
module a { ... import foo; ... }
module b { ... import foo; ... }
Do we require a server that implements both a and b to use the
same revision of foo?
If the answer is yes, we need to indicate the default revision
that the server uses in the model:
container modules {
...
list module {
...
leaf default-revision {
type boolean;
default false;
description
Indicates that this revision is used by the server if
this module is imported without a specific revision
date.;
}
}
}
If the answer is no, note that this puts an implementation burden
on the client. A client cannot simply download all listed
modules, and load/compile/process them as one set.
If the anwser is no, I propose that we extend the module as such:
container modules {
...
list module {
...
list imported-without-revision {
key name revision;
...
}
}
}
A server could then list:
module
namea/name
revision2015-01-01/revision
imported-without-revision
namefoo/name
revision2002-02-02/revision
/imported-without-revision
/module
module
nameb/name
revision2015-01-01/revision
imported-without-revision
namefoo/name
revision2001-01-01/revision
/imported-without-revision
/module
I believe truth is advertisement is a good thing. In the SNMP world,
not all pieces of the instrumentation were moving at the same pace and
I would be somewhat surprised if this would be the case for all
implementations in the NETCONF world. Hence, I rather accept that an
import of foo without revision may resolve to different versions of
foo for different imports.
/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
