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 <[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 > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
