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

[Martin Bjorklund <[e-mail]>]

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 <[e-mail]> 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 <[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/>
>