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

[Benoit Claise <[e-mail]>]

On 1/23/2017 5:26 PM, Ladislav Lhotka wrote:
>> On 23 Jan 2017, at 16:51, Robert Wilton <[e-mail]> wrote:
>>
>> I would suggest tweaking the order of the words slightly:
>>
>> Old:
>>
>> The interpretation of any other character then the ones listed above
>> following a backslash is undefined. Authors are advised to avoid using
>> such backslash sequences in double-quoted strings in their YANG
>> modules.
>>
>> New:
>>
>> The interpretation of any character other than the ones listed above
>> following a backslash is undefined. Authors are advised to avoid using
>> such backslash sequences in double-quoted strings in their YANG
>> modules.
> +1
>
> Otherwise I like the text.
Good.
Errata approved.

Regards, B.
>
> Lada
>
>>   
>>
>> Thanks,
>> Rob
>>
>>
>> On 23/01/2017 15:41, Benoit Claise wrote:
>>> On 1/23/2017 4:33 PM, Martin Bjorklund wrote:
>>>> Benoit Claise <[e-mail]> wrote:
>>>>> On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:
>>>>>>> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
>>>>>>> <[e-mail]> wrote:
>>>>>>>
>>>>>>> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
>>>>>>>> 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.
>>>>>>> Exactly. But other interpretations are legal as well. We can not
>>>>>>> retroactively turn so far conforming implementations of the RFC into
>>>>>>> non-conforming implementations (via an errata that introduces a MUST
>>>>>>> that was not there in the beginning).
>>>>>>>
>>>>>>>> This would be fine for the "Notes" part but RFC Errata require also
>>>>>>>> "Original Text" and "Corrected Text". Any suggestion for this?
>>>>>>> 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 interpretation of any other character then the ones listed above
>>>>>>> following a backslash is undefined. Authors are advised to avoid using
>>>>>>> such backslash sequences in double-quoted strings in their YANG
>>>>>>> modules.
>>>>>> OK, this looks good. Benoit, will you first reject the existing
>>>>>> errata?
>>>>> Instead of rejected, I modified the errata 4911.
>>>>> A final check please before I approve it.
>>>>> https://www.rfc-editor.org/errata_search.php?eid=4911
>>>> Hmm, I still just see the orignal errata text when I follow this link.
>>> Now saved :-)
>>>
>>> B.
>>>>
>>>> /martin
>>>> .
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>
> .
>