Hi, I agree with what Juergen writes below.
Also, if we *really* wanted to change RFC 6020 in this regard (which I don't think we should!), I think the change should be the equivalent of Y06-01: Clarify that "\x" means the two characters '\' and 'x', i.e., "\x" is equivalent to '\x'. This is how several known implementations have interpreted the text. I think that this was the original intention of the text. (Yes, I know that there are issues with this design, but that's not the point here). /martin Juergen Schoenwaelder <[email protected]> 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. 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 <[email protected]> > > > > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
