On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev <[email protected] > wrote:
> On 10/24/2017 03:42 AM, Andy Bierman wrote: > > >> >> On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev < >> [email protected] <mailto:[email protected]>> wrote: >> >> On 10/23/2017 01:35 PM, Martin Bjorklund wrote: >> >> Vladimir Vassilev <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hello, >> >> I would like to use the occasion of this Errata report to >> point out >> some additional issues with the instance-identifier type >> definition. >> >> IMO the instance-identifier built-in type has 2 additional >> problems >> that can be addressed with alternative and significantly >> more radical >> errata or fixed in a new version of YANG.: >> >> Problem 1: The obvious limitation inherited from Xpath 1.0 >> - inability >> to escape single or double quote characters. In Xpath >> world this >> limitation is worked around by use of concat() which is >> not available >> in the YANG 1.1 instance-identifier definition. 2 examples >> of this >> limitation: >> >> 1. It is impossible to create value of type >> instance-identifier >> referencing nodes in lists with key string values >> containing both a >> single and a double quote characters e.g. >> ...<interface><name>"It's >> valid string!"</name></interface>. >> >> 2. Another example of the same problem would be a leaf of type >> instance-identifier referencing another leaf of type >> instance-identifier. With 2 references it works provided >> one is >> encoded with single quotes and the other with double but it is >> impossible to create third e.g. >> >> YANG: >> >> list id-list { >> key "id"; >> >> leaf id { >> type instance-identifier; >> } >> } >> >> >> >> >> Although the instance-identifier is problematic, it is rarely used at all, >> let alone using it as a list key. >> > It is used as a key in ietf-alarms /alarms/alarm-list/alarm. > >> >> The XPath mixed-quotes problem is well-known, and the suggested >> solution seems to be use the "concat" function >> >> /foo/bar[name=concat("It's a", ' "valiid" string')] >> >> Not very user friendly, is it? >> > I think people naming their interfaces "It's a valid string!" can take it. > Prettier escaping solutions are available e.g. C string but it will require > more work then a line in the next YANG version RFC. IMO solution is needed > either concat or an alternative one. > > Practical reason: YANG 1.1 can not create instance-identifier to the alarm > /alarms/alarm-list/alarm[... resource="/interfaces/interface[name='eth0']"]. > And this is not the "That's a valid string!" named interface. The "That's a > valid string!" interface alarms can not be reported as a valid ietf-alarms > instance-identifier based resource alarm at all. > Actually the XPath designers made a reasonable trade-off by using concat as the solution to a problem that rarely happens. It is up to the IETF to define YANG in a way that does not ignore the XPath solutions. Andy > >> >> Data: >> >> * /top/id-list[id="/top/list[idx='4']"] >> >> * /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"] >> <assuming the >> * proposed errata is also in effect> >> >> * <next reference not possible with YANG 1.1> >> >> Problem 2: The instance-identifier type lacks canonical >> form (which >> makes it the only data type with implementation dependent >> representation at the data level ... think of the integer >> types >> allowing optional spaces between the digits). This is in >> fact the only >> built-in data type that allows the server implementation >> to change the >> configuration data replacing double quotes with single or >> the other >> way around. Inserting white spaces where you did not have >> them when >> the configuration was submitted. You can not simply read a >> configuration and use fast data comparison without schema >> support just >> because of this type. This is useless flexibility for >> simple data >> type. >> >> And this can be fixed if: >> >> 1. white spaces in instance-identifiers are prohibited >> >> >> 2. list key predicates are required in alphabetical order >> >> Or perhaps use the order the keys are defined in the data >> model (the >> "keys" statement"). >> >> This is an option but then the e.g. xpath2instid() function >> implementations will need schema support. >> >> >> >> All the YANG tools I have seen generate the predicates in YANG key order. >> > Yes. > > If Xpath came with a canonical form definition (prohibiting spaces, > redundant duplication of namespace prefixes in children, order of > predicates, canonical quotation rule, and some flexibility as of the node > prefix semantics) we would not need to have this discussion. Seems no other > modeling language of hierarchical data has reusable instance-identifier > datatype with the necessary properties and I can see this as something that > can go in separate RFC specifying generic data type making canonic > definition from Xpath that YANG can reuse. In that case the alphabetic > order makes sense moving some constraints into the generic definition of > the type one can validate without the context schema but it is not of > significant importance. > > The issue of canonical instance-identifier has been discussed many times, >> and it is not possible to require the usage of specific prefixes in XML. >> (Note that Lada fixed this for JSON in RFC 7951) >> > Yes. > >> >> Only the string + expanded names can be properly compared in XML, not the >> literal string >> representing the XPath expression. >> > Yes. > > I do not see the need of major rework just making the Xpath subset rules > stricter with canonical requirement and either allowing concat() (also with > canonic rule producing predictable result e.g. to be used only for escaping > single quotes and prohibiting double quotes in predicates otherwise). Even > with RFC7951 prefix rules added in the instance-identifier can still be a > valid Xpath subset requiring trivial prefix replacements so that it can be > used with non-YANG aware XML tools keeping that option open. > > Vladimir > >> >> >> Vladimir >> >> >> >> Andy >> >> >> 3. strict quotation convention with escape option is >> added. (only >> 3. contradicts the sec. 9.13 ".. instance-identifier is a >> subset of >> the XPath ..") >> >> I would like to change one more thing - I think it is >> unfortunate that >> the lexical representation depends on the lexical context; >> specifically that prefixes declared in the XML instance >> document is >> used. This applies also to identityref. YANG 2.0 should use >> the same >> encoding as JSON does for these datatypes. >> >> >> >> /martin >> >> >> >> Vladimir >> >> On 10/21/2017 08:16 PM, Andy Bierman wrote: >> >> >> On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> wrote: >> >> Dear all, >> >> Shall I validate this one? >> >> >> >> To add more context, this relates to the the RESTCONF >> JSON vs. XML >> discussions in the NETCONF WG. >> >> leaf broken { >> type union { >> type int32; >> type string; >> } >> } >> >> If all values of key leaf "broken" are sent as strings >> in an >> instance-identifier, >> then the int32 value may not match in all >> implementations, instead of >> the string. >> Allowing numbers as literals in addition to quoted >> strings allows the >> sender >> to be specific, and all implementations to be consistent. >> >> >> Regards, Benoit >> >> >> >> Andy >> >> The following errata report has been >> submitted for RFC7950, >> "The YANG 1.1 Data Modeling Language". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5157 >> <http://www.rfc-editor.org/errata/eid5157> >> <http://www.rfc-editor.org/errata/eid5157 >> <http://www.rfc-editor.org/errata/eid5157>> >> >> -------------------------------------- >> Type: Technical >> Reported by: Andy Bierman <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> >> >> Section: 14 >> >> Original Text >> ------------- >> key-predicate-expr = node-identifier *WSP >> "=" *WSP >> quoted-string >> >> Corrected Text >> -------------- >> key-predicate-expr = node-identifier *WSP >> "=" *WSP >> (quoted-string / integer-value / >> decimal-value) >> >> Notes >> ----- >> An instance identifier is forced to specify >> every key value to >> be a string >> even though the YANG key leaf type could be a >> numeric type. >> XPath does not require a quoted string here, >> just YANG. >> >> Old: /top/list[idx="4"] >> New: /top/list[idx=4] >> >> Instructions: >> ------------- >> This erratum is currently posted as >> "Reported". If necessary, >> please >> use "Reply All" to discuss whether it should >> be verified or >> rejected. When a decision is reached, the >> verifying party >> can log in to change the status and edit the >> report, if necessary. >> >> -------------------------------------- >> RFC7950 (draft-ietf-netmod-rfc6020bis-14) >> -------------------------------------- >> Title : The YANG 1.1 Data >> Modeling Language >> Publication Date : August 2016 >> Author(s) : M. Bjorklund, Ed. >> Category : PROPOSED STANDARD >> Source : NETCONF Data Modeling >> Language >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> . >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://www.ietf.org/mailman/listinfo/netmod> >> >> _______________________________________________ >> netmod mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://www.ietf.org/mailman/listinfo/netmod> >> >> >> >> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
