> On 18 Jan 2017, at 15:44, Martin Bjorklund <[email protected]> wrote: > > Ladislav Lhotka <[email protected]> wrote: >> >>> On 18 Jan 2017, at 14:55, Martin Bjorklund <[email protected]> wrote: >>> >>> RFC Errata System <[email protected]> wrote: >>>> 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. >>> >>> I don't think this errata should be accepted. As stated, the spec is >>> unclear, and YANG 1.1 has fixed this problem. But it is not clear >>> that the original intention when RFC 6020 was written was #1. >>> Accepting this errata now would make existing implementations and >>> modules invalid. >> >> The problem is that the spec is clearly ambiguous > > Agreed.
Then isn't it an error that needs to be corrected? > >> and it is >> impossible to decide whether such a module is valid or not and, if >> it is, what the other backslash-escaped characters mean. Existing >> implementations can already reject such modules - the fact that >> pyang (and probably other tail-f tools) adopted one interpretation >> doesn't mean that everybody does the same. > > This is exactly my point. But it means that different tools may give different results, e.g. when matching a string against such a pattern. > >>> The solution moving forward is to use YANG 1.1. >>> >> >> YANG 1.0 modules continue to be written, and I think it is important >> to stop this problem from spreading further. I think tools should >> at least issue a warning because otherwise future upgrades to YANG >> 1.1 may become a nightmare - modules will suddenly break in >> unexpected places. > > Sure, but that's a different story (I already added a warning for this > in pyang). > >> If this erratum is rejected, what is the basis for accepting erratum >> #4909 that started this discussion? > > That module relied on one interpretation, but as you write, the spec > is unclear and toold behave differently. Thus, modules should avoid > this pattern. > It might suffice to just warn readers of RFC 6020 that this issue exists and should be avoided by using single quotes. Unfortunately, RFC errata only seem to support explicit "patches" to the text but not such comments. Lada > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
