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

Andy Bierman <andy@yumaworks.com> Tue, 24 October 2017 17:06 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E42C138FA0 for <netmod@ietfa.amsl.com>; Tue, 24 Oct 2017 10:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3ZoODf-iQII for <netmod@ietfa.amsl.com>; Tue, 24 Oct 2017 10:06:54 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A451138103 for <netmod@ietf.org>; Tue, 24 Oct 2017 10:06:54 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id a2so2729178lfh.11 for <netmod@ietf.org>; Tue, 24 Oct 2017 10:06:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/o4eaNoTpV9+gDuLTIM9Vq1Fy/kdaFkDLaIr5N/escQ=; b=HC/0qk8tdgE3wszk0wvRzHl6xQ/PaYtJBOGlG3cewAYtpp50ecVzFP//TzwD5W9OOc Viwc/ujna0zTrTB+EEcUVZjD2yHQcBXpUwfdnMew7nH/L5g1khTl+7d+7cepT24t4iob BACLWEQXPa2n+sVQUHhbdLqHk6sk9vo1ZYqvxX/HdbbXOGWNSZIaY67kVZIINsCLFF1Q r4QaI9zHF+ariWvRYfEygIdn0pg83J3crhiytHzqNPXx8rlc0NgFzR3ehBlLqS75+Me/ db6h8WiUvV7TumzGT8BOu2lD76/2y4RYQAyQ2ZAsiSxn3y+kMjP/huzo0qrse8qMTw1D VSog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/o4eaNoTpV9+gDuLTIM9Vq1Fy/kdaFkDLaIr5N/escQ=; b=CeKXvMh0tQjF2QhcT7knEbiU/aJ51uYpAlcMh+pjrVwvVaAzxepLOFNePnxZVhpbUr otZS6OZmqE04U1uQt3on7bYWVnFBUZ0xB4Wd29BmWCtrHJeiNL+CwZL9NCrUY4oDYxhL clAY4cE+ckn9psp+Z+xWH8YaZkuIxpIuPO2bRvh5HQhPq3nZnPY7Q/omaAHECbYeYPkh nVKbv4Yefs0XqzMfj7bXeCSbmWOO1C8fkMZPUf4tM5AHE+Bww/o0MkqY0I4et1HeZ35Z GzIm2nojuSvc7lSAUYLin0nYl08k14BBqDR3TdNdcoxAUcELJhTqtPWEo//Ux76OtLO7 icpQ==
X-Gm-Message-State: AMCzsaVwdvDR+47CIORBxxtVvXaxB2U0H5YVgcszFJ1xR3Kqww0t/Xyw jZ5Te9/nVvmnuiLRfG8H1rgIXG5m+kv7wgDobcbfHQ==
X-Google-Smtp-Source: ABhQp+Th93GNX82UuXHP/4kChurTiZOrwPIGtpiiRxA195qy+qsMow2TbHFIENzU8PVcCZnHHcPYHFAh8X3qfFhPy8Q=
X-Received: by 10.25.211.73 with SMTP id k70mr5956681lfg.51.1508864812347; Tue, 24 Oct 2017 10:06:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Tue, 24 Oct 2017 10:06:51 -0700 (PDT)
In-Reply-To: <f3e87c29-2a21-4ace-d0e2-4f635b7aa13f@transpacket.com>
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com> <CABCOCHRP2ooSG1BGWehD8BsCDF-pX97Q++=WftOxGvf=S57GAQ@mail.gmail.com> <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com> <ca6baac5-b30a-de80-24e0-8463f01ec67f@transpacket.com> <CABCOCHRv-1JCq9GSP1KMCnm4fOi4TS_M9hUpNRt0Kn-PLdguww@mail.gmail.com> <f3e87c29-2a21-4ace-d0e2-4f635b7aa13f@transpacket.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 24 Oct 2017 10:06:51 -0700
Message-ID: <CABCOCHRu0bOE+Ftay3PG2pr6e+WMLgup350HusHQ42QH8U=1vA@mail.gmail.com>
To: Vladimir Vassilev <vladimir@transpacket.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a114188aa278f14055c4df7a8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/N-s_F__VfiNSYbjnC6dArpzLQIU>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Oct 2017 17:06:57 -0000

On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev <vladimir@transpacket.com
> wrote:

> On 10/24/2017 03:42 AM, Andy Bierman wrote:
>
>
>>
>> On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev <
>> vladimir@transpacket.com <mailto:vladimir@transpacket.com>> wrote:
>>
>>     On 10/23/2017 01:35 PM, Martin Bjorklund wrote:
>>
>>         Vladimir Vassilev <vladimir@transpacket.com
>>         <mailto:vladimir@transpacket.com>> 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
>>                 <bclaise@cisco.com <mailto:bclaise@cisco.com>
>>                 <mailto:bclaise@cisco.com <mailto:bclaise@cisco.com>>>
>>                 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 <andy@yumaworks.com
>>                 <mailto:andy@yumaworks.com>
>>                          <mailto:andy@yumaworks.com
>>                 <mailto:andy@yumaworks.com>>>
>>
>>                          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
>>                 netmod@ietf.org <mailto:netmod@ietf.org>
>>                 https://www.ietf.org/mailman/listinfo/netmod
>>                 <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>             _______________________________________________
>>             netmod mailing list
>>             netmod@ietf.org <mailto:netmod@ietf.org>
>>             https://www.ietf.org/mailman/listinfo/netmod
>>             <https://www.ietf.org/mailman/listinfo/netmod>
>>
>>
>>
>>
>