Re: [netmod] [Technical Errata Reported] RFC7950 (5157)

[Andy Bierman <[e-mail]>]

On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev <[e-mail]
> wrote:

> On 10/24/2017 03:42 AM, Andy Bierman wrote:
>
>
>>
>> On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev <
>> [e-mail] <mailto:[e-mail]>> wrote:
>>
>>     On 10/23/2017 01:35 PM, Martin Bjorklund wrote:
>>
>>         Vladimir Vassilev <[e-mail]
>>         <mailto:[e-mail]>> 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
>>                 <[e-mail] <mailto:[e-mail]>
>>                 <mailto:[e-mail] <mailto:[e-mail]>>>
>>                 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 <[e-mail]
>>                 <mailto:[e-mail]>
>>                          <mailto:[e-mail]
>>                 <mailto:[e-mail]>>>
>>
>>                          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
>>                 [e-mail] <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/listinfo/netmod
>>                 <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>             _______________________________________________
>>             netmod mailing list
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/netmod
>>             <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>
>>
>>
>