Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Lou Berger <[e-mail]>]

How do you feel about an errata on 1.0 that it should be considered to
be updated by 1.1?

Lou


On 1/23/2017 6:08 AM, Benoit Claise wrote:
> On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
>> Benoit,
>>
>> RFC 6020 is ambiguous and this is just how it is. The solution for
>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>> character sequences (and avoiding ambiguity can be easily done).
>>
>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>> implementation into a non-conforming implementation. Hence, this may
>> go beyond the scope of an errata.
>>
>> If tools generate proper warnings, I think we are fine and we do not
>> need to change YANG 1. These kind of issues are caught by tools, not
>> by humans reading language specifications.
>>
>> If you feel strongly that an errata is needed, then the errata should
>> simply clearly spell out that certain backslahs sequences are
>> ambiguous and provide advice that they should not be used.
> That would work.
> Can we modify the errata this way.
>
> Regards, Benoit
>> This is
>> backwards compatible. Making them illegal is not backwards compatible.
>>
>> /js
>>
>> PS: This is also my recollection of the discussion of issue Y06 when
>>      YANG 1.1 was put together.
>>
>> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
>>> Dear all,
>>>
>>> Let me summarize the situation.
>>>      - The RFC 6020 spec is clearly ambiguous.
>>>      - The solution is to use YANG 1.1
>>>      - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>>>      - We should stop this problem from spreading further: updating tooling
>>> is one good aspect, we should update the spec. too to at least warn the
>>> users.
>>>
>>> There is no perfect solution.
>>> Because of (*), I believe I should accept this errata.
>>> Any strong objections? If you have, propose a better plan. And I don't
>>> believe that "do nothing" is sufficient.
>>>
>>> Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>>>
>>>     (16) Will publication of this document change the status of any
>>>     existing RFCs? Are those RFCs listed on the title page header, listed
>>>     in the abstract, and discussed in the introduction? If the RFCs are not
>>>     listed in the Abstract and Introduction, explain why, and point to the
>>>     part of the document where the relationship of this document to the
>>>     other RFCs is discussed. If this information is not in the document,
>>>     explain why the WG considers it unnecessary.
>>>
>>>        No. YANG 1.0 [RFC6020] is not expected to change its status since
>>>        there are data models on the standards-track that conform to YANG
>>>        1.0. YANG 1.0 may be considered for retirement once all data models
>>>        have naturally been updated to a future version of YANG.
>>>
>>> Regards, Benoit
>>>> The following errata report has been submitted for RFC6020,
>>>> "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Ladislav Lhotka <[e-mail]>
>>>>
>>>> Section: 6.1.3
>>>>
>>>> Original Text
>>>> -------------
>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>> character introduces a special character, which depends on the
>>>> character that immediately follows the backslash:
>>>>
>>>>    \n      new line
>>>>    \t      a tab character
>>>>    \"      a double quote
>>>>    \      a single backslash
>>>>
>>>>
>>>> Corrected Text
>>>> --------------
>>>> Within a double-quoted string (enclosed within " "), a backslash
>>>> character introduces a special character, which depends on the
>>>> character that immediately follows the backslash:
>>>>
>>>>    \n      new line
>>>>    \t      a tab character
>>>>    \"      a double quote
>>>>    \      a single backslash
>>>>
>>>> The backslash MUST NOT be followed by any other character.
>>>>
>>>> Notes
>>>> -----
>>>> The text doesn't state whether other characters may follow the backslash, and if yes, what it means. Existing implementations have used three approaches:
>>>>
>>>> 1. report an error if another character follows the backslash
>>>> 2. keep only the character following the backslash, i.e., for example, "\x" is the same as "x".
>>>> 3. keep both the backslash and the character following it.
>>>>
>>>> This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option #1. However, many modules are still being written using YANG version 1.0, so it is important to clarify this issue in RFC 6020 as well.
>>>>
>>>> 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.
>>>>
>>>> --------------------------------------
>>>> RFC6020 (draft-ietf-netmod-yang-13)
>>>> --------------------------------------
>>>> Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
>>>> Publication Date    : October 2010
>>>> 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]
>>> https://www.ietf.org/mailman/listinfo/netmod
>