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

[Ladislav Lhotka <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> writes:

> 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.

But it is not really the case here because it cannot be decided what
conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
don't think it is less conforming than any other.

>
> 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. This is
> backwards compatible. Making them illegal is not backwards compatible.

This would be fine for the "Notes" part but RFC Errata require also
"Original Text" and "Corrected Text". Any suggestion for this?

Lada

>
> /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
>
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67