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

[Juergen Schoenwaelder <[e-mail]>]

Lou,

RFC 7950 does not update anything in RFC 6020.

In hindsight, the proper tag would have been 'Obsoletes: RFC 6020' but
that was considered too 'aggressive' at that time and now it is too
late to put it in.

I suggest to leave it alone. People who simply google 'yang rfc' will
hopefully find the latest version. ;-)

/js

On Mon, Jan 23, 2017 at 11:09:53AM -0500, Lou Berger wrote:
> 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 <[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
> >
> 
> _______________________________________________
> 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/>