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

[Benoit Claise <[e-mail]>]

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
>