Vladimir Vassilev <[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;
>       }
>     }
> 
> 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").

> 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]>> 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>
> >
> >         --------------------------------------
> >         Type: Technical
> >         Reported by: Andy Bierman <[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]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
> 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to