Re: [netmod] yang 1.1 last call comment resolution
Andy Biermanwrote: > On Mon, Nov 9, 2015 at 11:55 AM, Randy Presuhn > wrote: > > > Hi - > > > > >From: Martin Bjorklund > > >Sent: Nov 9, 2015 10:27 AM > > >To: a...@yumaworks.com > > >Cc: netmod@ietf.org > > >Subject: Re: [netmod] yang 1.1 last call comment resolution > > ... > > >> > - Old function: unique module names > > >> > > > >> > I think the resolution is to adopt the compromise solution. > > >> > > > >> > > >> which was what? > > > > > >The (revised) proposal is: > > > > > > The names of all standard modules and submodules MUST be unique. > > > Developers of enterprise modules are RECOMMENDED to choose names for > > > their modules that will have a low probability of colliding with > > > standard or other enterprise modules, e.g., by using the enterprise > > > or organization name as a prefix for the module name. Witin a > > > server, all module names MUST be unique. > > > > This doesn't make sense from the perspective of the RFC 2119 > > guidelines. The choice between MUST and RECOMMENDED is effectively > > governed by the question "would failure to comply with this > > constraint prevent successful interoperation". It's *not* a > > question of whether the modules are "standard" (does that include > > non-IETF efforts?) or "enterprise". Either they're both "MUST" > > or they're both "SHOULD/RECOMMENDED". > > > > > I agree the first sentence is odd. > It does not include Experimental modules that bypass the WG process, > like the time-capability module. > > NEW: > > Developers of YANG modules are RECOMMENDED to choose names for > their modules that will have a low probability of colliding with > standard or other enterprise modules, e.g., by using the enterprise > or organization name as a prefix for the module name. Within a > server, all module names MUST be unique. Ok with me. > The YANG guidelines will say that any YANG module in > an RFC MUST have uniqueu module and submodule names. Ok. /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y10 clarification
Andy Biermanwrote: > On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund wrote: > > > Hi, > > > > I implemented most of the 1.1 features that affect the compiler in > > pyang on the flight back from Yokohama. (if you have 1.1 modules, I'd > > appreciate if you could try it out). > > > > In doing this, I realized that I forgot one part of Y10 - "allow > > restrictions on enumerations". If we allow: > > > > typedef foo2 { > > type enumeration { > > enum a; > > enum b; > > } > > } > > typedef bar2 { > > type foo2 { > > enum a; > > } > > } > > > > we should also allow: > > > > typedef foo2 { > > type bits { > > bit a; > > bit b; > > } > > } > > typedef bar2 { > > type foo2 { > > bit a; > > } > > } > > > > It is briefly mentioned in the description of Y10. > > > > > > Comments? > > > > > Yet more complexity without any real use-cases? It is a matter of removing CLRs and inconsistencies. > How does auto-numbering work in both cases? > > > typedef foo2 { > type enumeration { > enum a; > enum b; > } > } > > typedef foo3 { > type foo2 { > enum b; > } > } > > typedef bar1 { > type enumeration { > enum b; > } > } > > > What is the auto-numbering of enum 'b' in type foo3? There is none. The text says: When an existing enumeration type is restricted, the "value" statement MUST either have the same value as in the base type or not be present, in which case the value is the same as in the base type. > What value does type foo3 have over bar1? Unless the type has some semantics, there is none. But when the type has some semantics, the possibility to restrict an existing type is useful. If it not useful for enumerations and bits, why should we have it for strings and ints, for example. /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y10 clarification
On Mon, Nov 9, 2015 at 1:11 PM, Martin Bjorklundwrote: > Andy Bierman wrote: > > On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund > wrote: > > > > > Hi, > > > > > > I implemented most of the 1.1 features that affect the compiler in > > > pyang on the flight back from Yokohama. (if you have 1.1 modules, I'd > > > appreciate if you could try it out). > > > > > > In doing this, I realized that I forgot one part of Y10 - "allow > > > restrictions on enumerations". If we allow: > > > > > > typedef foo2 { > > > type enumeration { > > > enum a; > > > enum b; > > > } > > > } > > > typedef bar2 { > > > type foo2 { > > > enum a; > > > } > > > } > > > > > > we should also allow: > > > > > > typedef foo2 { > > > type bits { > > > bit a; > > > bit b; > > > } > > > } > > > typedef bar2 { > > > type foo2 { > > > bit a; > > > } > > > } > > > > > > It is briefly mentioned in the description of Y10. > > > > > > > > > Comments? > > > > > > > > Yet more complexity without any real use-cases? > > It is a matter of removing CLRs and inconsistencies. > > > How does auto-numbering work in both cases? > > > > > > typedef foo2 { > > type enumeration { > > enum a; > > enum b; > > } > > } > > > > typedef foo3 { > > type foo2 { > > enum b; > > } > > } > > > > typedef bar1 { > > type enumeration { > > enum b; > > } > > } > > > > > > What is the auto-numbering of enum 'b' in type foo3? > > There is none. The text says: > > When an existing enumeration type is restricted, the "value" > statement MUST either have the same value as in the base type or not > be present, in which case the value is the same as in the base type. > > good Is the refinement allowed to add, remove, or change if-feature-stmts? I don't remember seeing any text on that. > > What value does type foo3 have over bar1? > > Unless the type has some semantics, there is none. But when the type > has some semantics, the possibility to restrict an existing type is > useful. If it not useful for enumerations and bits, why should we > have it for strings and ints, for example. > > so the reason to do this would be to restrict the value set but maintain the value and position assignments. OK > /martin > Andy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] JSON encoding of anyxml
Hi, I am not in favor of anything XML or JSON specific in YANG. In reality, nobody uses anyxml as a configuration data node, so an improper roundtrip translation from JSON to XML is not going to happen. Encoding anyxml as a string is not going to happen either. Not sure what the difference between 'anyxml' and 'type string' is at that point. Why does YANG even need a special type of leaf that is a blob of XML? Can't a single-quoted string serve that purpose? Andy On Mon, Nov 9, 2015 at 2:39 PM, Robert Vargawrote: > On 11/05/2015 09:56 AM, Ladislav Lhotka wrote: > >> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode >>> >anyxml as a string that has XML inside makes sense. >>> >> The possibility of sending arbitrary (non-YANG) data in the native >> encoding can occassionally be useful, and even more so in JSON. For >> example, I have to work with a JSON-based format for specifying DNSSEC >> signing policies. While my plan is to eventually replace this format with >> YANG-modelled data, it would help me, as an interim solution, to simply >> send the data in the legacy format. That's why I want to retain the >> existing rules for JSON encoding of anyxml, unless something else is >> available. Sending XML documents as strings is still possible although IMO >> next to useless. >> > > I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies > non-transparent in case the sender (a NETCONF NE) and receiver (an RESTCONF > application) have out-of-band knowledge of the data being sent over anyxml. > Given the proxy does not have this knowledge, it cannot reliably deal with > lists, as they lack a container element in XML encoding. > > Can we perhaps indicate the encoding of the anyxml data chunk in JSON as a > separate well-known attribute? > > Bye, > Robert > > ___ > 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
[netmod] Y10 clarification
Hi, I implemented most of the 1.1 features that affect the compiler in pyang on the flight back from Yokohama. (if you have 1.1 modules, I'd appreciate if you could try it out). In doing this, I realized that I forgot one part of Y10 - "allow restrictions on enumerations". If we allow: typedef foo2 { type enumeration { enum a; enum b; } } typedef bar2 { type foo2 { enum a; } } we should also allow: typedef foo2 { type bits { bit a; bit b; } } typedef bar2 { type foo2 { bit a; } } It is briefly mentioned in the description of Y10. Comments? /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] yang 1.1 last call comment resolution
On Mon, Nov 9, 2015 at 11:55 AM, Randy Presuhnwrote: > Hi - > > >From: Martin Bjorklund > >Sent: Nov 9, 2015 10:27 AM > >To: a...@yumaworks.com > >Cc: netmod@ietf.org > >Subject: Re: [netmod] yang 1.1 last call comment resolution > ... > >> > - Old function: unique module names > >> > > >> > I think the resolution is to adopt the compromise solution. > >> > > >> > >> which was what? > > > >The (revised) proposal is: > > > > The names of all standard modules and submodules MUST be unique. > > Developers of enterprise modules are RECOMMENDED to choose names for > > their modules that will have a low probability of colliding with > > standard or other enterprise modules, e.g., by using the enterprise > > or organization name as a prefix for the module name. Witin a > > server, all module names MUST be unique. > > This doesn't make sense from the perspective of the RFC 2119 > guidelines. The choice between MUST and RECOMMENDED is effectively > governed by the question "would failure to comply with this > constraint prevent successful interoperation". It's *not* a > question of whether the modules are "standard" (does that include > non-IETF efforts?) or "enterprise". Either they're both "MUST" > or they're both "SHOULD/RECOMMENDED". > > I agree the first sentence is odd. It does not include Experimental modules that bypass the WG process, like the time-capability module. NEW: Developers of YANG modules are RECOMMENDED to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name. Within a server, all module names MUST be unique. The YANG guidelines will say that any YANG module in an RFC MUST have uniqueu module and submodule names. Randy > 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] Y10 clarification
On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklundwrote: > Hi, > > I implemented most of the 1.1 features that affect the compiler in > pyang on the flight back from Yokohama. (if you have 1.1 modules, I'd > appreciate if you could try it out). > > In doing this, I realized that I forgot one part of Y10 - "allow > restrictions on enumerations". If we allow: > > typedef foo2 { > type enumeration { > enum a; > enum b; > } > } > typedef bar2 { > type foo2 { > enum a; > } > } > > we should also allow: > > typedef foo2 { > type bits { > bit a; > bit b; > } > } > typedef bar2 { > type foo2 { > bit a; > } > } > > It is briefly mentioned in the description of Y10. > > > Comments? > > Yet more complexity without any real use-cases? How does auto-numbering work in both cases? typedef foo2 { type enumeration { enum a; enum b; } } typedef foo3 { type foo2 { enum b; } } typedef bar1 { type enumeration { enum b; } } What is the auto-numbering of enum 'b' in type foo3? What value does type foo3 have over bar1? > /martin > 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] Y10 clarification
Andy Biermanwrote: > On Mon, Nov 9, 2015 at 1:11 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund > > wrote: > > > > > > > Hi, > > > > > > > > I implemented most of the 1.1 features that affect the compiler in > > > > pyang on the flight back from Yokohama. (if you have 1.1 modules, I'd > > > > appreciate if you could try it out). > > > > > > > > In doing this, I realized that I forgot one part of Y10 - "allow > > > > restrictions on enumerations". If we allow: > > > > > > > > typedef foo2 { > > > > type enumeration { > > > > enum a; > > > > enum b; > > > > } > > > > } > > > > typedef bar2 { > > > > type foo2 { > > > > enum a; > > > > } > > > > } > > > > > > > > we should also allow: > > > > > > > > typedef foo2 { > > > > type bits { > > > > bit a; > > > > bit b; > > > > } > > > > } > > > > typedef bar2 { > > > > type foo2 { > > > > bit a; > > > > } > > > > } > > > > > > > > It is briefly mentioned in the description of Y10. > > > > > > > > > > > > Comments? > > > > > > > > > > > Yet more complexity without any real use-cases? > > > > It is a matter of removing CLRs and inconsistencies. > > > > > How does auto-numbering work in both cases? > > > > > > > > > typedef foo2 { > > > type enumeration { > > > enum a; > > > enum b; > > > } > > > } > > > > > > typedef foo3 { > > > type foo2 { > > > enum b; > > > } > > > } > > > > > > typedef bar1 { > > > type enumeration { > > > enum b; > > > } > > > } > > > > > > > > > What is the auto-numbering of enum 'b' in type foo3? > > > > There is none. The text says: > > > > When an existing enumeration type is restricted, the "value" > > statement MUST either have the same value as in the base type or not > > be present, in which case the value is the same as in the base type. > > > > > > good > > Is the refinement allowed to add, remove, or change if-feature-stmts? > I don't remember seeing any text on that. The refine statement cannot address individual enums/bits (it can only address structure) so the answer is that it is not possible to change if-feature on enums/bits in refinements. > > > What value does type foo3 have over bar1? > > > > Unless the type has some semantics, there is none. But when the type > > has some semantics, the possibility to restrict an existing type is > > useful. If it not useful for enumerations and bits, why should we > > have it for strings and ints, for example. > > > > > > so the reason to do this would be to restrict the value set but > maintain the value and position assignments. OK /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] yang 1.1 last call comment resolution
Andy Biermanwrites: > On Thu, Nov 5, 2015 at 1:20 AM, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: >> ... >> > - Old function: make auto-delete for choice and when non-NETCONF specific >> > >> > Revision -08 of YANG 1.1 defines auto-deletion as a property of the >> > NETCONF edit-config operation and the issue is whether this >> > auto-deletion behaviour is a NETCONF specific edit-config property >> > or a general YANG datastore validation property that equally applies >> > to RESTCONF, COMI, ... >> > >> > It is unclear where we are with this. More input would be welcome. >> >> I think it would be very confusing if e.g. RESTCONF behaved >> differently than NETCONF. However, I can see how it might make sense >> for a server on a constrained device to not do auto-delete - but OTOH >> such a server probably don't do "must" and "when" checking at all. >> And it might have specialized data models that don't use such >> constructs. >> >> >> > I don't like any of the NETCONF-specific text in YANG 1.1. > YANG datastore constraints refer to a conceptual "valid datastore". > There is no reason to talk about specific protocol behavior, > except that we are too lazy to put protocol text where it belongs. Agreed. > > It should at least be clear that datastore validation does not at all depend > on how the datastore contents were changed. The current text does > not even fully support , so it does not even support NETCONF, > let alone RESTCONF. > > IMO auto-deletion should not be changed. > It works fine and the only issue that has ever come up is > auto-deleting data from an edit-config payload. IMO a scarier prospect is the ripple effect where an edit-config causes some remote part(s) of the data tree to disappear. I looked into the existing uses of "when" and none of them seems to be really designed for the auto-deletion option. That is, auto-deletion is either impossible (e.g. if "when" involves just a list key) or otherwise it would clearly be an operator error (e.g. if interface type is changed by mistake). Lada > > > > > > /martin >> >> > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod