Subject: [netmod] [Technical Errata Reported] RFC6020 (4911)

From: RFC Errata System <[email-masked]>
Date: Wed, 18 Jan 2017 03:48:58 -0800 (PST)

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-masked]>

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Jan 2017 14:55:32 +0100 (CET)

RFC Errata System <[email-masked]> wrote:
> The text doesn't state whether other characters may follow the
> backslash, and if yes, what it means. Existing implementations have
> used three approaches:
> 
> 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 solution moving forward is to use YANG 1.1.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Jan 2017 15:24:22 +0100

> On 18 Jan 2017, at 14:55, Martin Bjorklund <[email-masked]> wrote:
> 

The problem is that the spec is clearly ambiguous 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.

> 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.

If this erratum is rejected, what is the basis for accepting erratum #4909 that started this discussion?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Benoit Claise <[email-masked]>
Date: Wed, 18 Jan 2017 15:37:41 +0100

Removing RFC Editor <[email-masked]>

See in-line.
> 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…
Now two good news.

First, pyang now includes a warning for YANG 1.0 modules:

    $ pyang [email-masked]
    [email-masked]:259: warning: the escape sequence
    "\S" is unsafe in double quoted strings - pass the flag
    --lax-quote-checks to avoid this warning

Thanks Martin for the speedy update. Note that this error message it was 
already present for YANG 1.1, as this is covered by RFC 7950.

Second, I ran all my scripts with the new pyang version, and no IETF 
YANG 1.0 modules face that issue 
(http://www.claise.be/IETFYANGPageCompilation.html)

However, we observed that some proprietary YANG 1.0 modules face this 
issue.
> If this erratum is rejected, what is the basis for accepting erratum #4909 that started this discussion?
Exact same question on my side.

Regards, Benoit
> .

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Jan 2017 15:44:12 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> The problem is that the spec is clearly ambiguous

Agreed.

> 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.

> 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).

> #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.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Wed, 18 Jan 2017 14:54:14 +0000

Hi Lada,

I don't feel strongly, but basically agree with Martin.

The YANG 1.0 spec is ambiguous, YANG 1.1 has fixed that.  I guess that 
most pragmatic YANG 1.0 implementations would treat a backslash followed 
by something other than n,t,", or / as just a backslash character.

This issue seems to only come up in the context of pattern statements.

The best pragmatic answer that I've seen to this is from rfc6087bis 
section 5.11.2: "Patterns and Ranges" which states that implementations 
SHOULD use single quotes rather than double quotes for patterns and 
hence carefully side steps the issue.

This is the solution that we used to fix the issue in our proprietary 
modules, and also the one that I recommended to OpenConfig for their 
models (but I don't know whether they will implement this).

Rob

On 18/01/2017 14:24, Ladislav Lhotka wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

---

From: William Lupton <[email-masked]>
Date: Wed, 18 Jan 2017 14:56:58 +0000

Reading RFC 6020 there is no “Obsoleted by RFC 7950” or “Updated by RFC 7950”. I expect that this is technically correct but it means that anyone reading RFC 6020 will not be aware of the existence of RFC 7950 and YANG 1.1. This seems unfortunate. W.

> On 18 Jan 2017, at 13:55, Martin Bjorklund <[email-masked]> wrote:
...

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 18 Jan 2017 15:58:09 +0100

> On 18 Jan 2017, at 15:44, Martin Bjorklund <[email-masked]> wrote:
> 

Then isn't it an error that needs to be corrected?

> 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.

> is unclear and toold behave differently.  Thus, modules should avoid

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jan 2017 20:34:02 +0100

> Accepting this errata now would make existing implementations and

+1

And I note that this is inline with the discussions we had when YANG
1.1 was put together. We should not waste cycles rehashing issues.

/js

-- 
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/>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 18 Jan 2017 16:08:57 -0500

> \      a single backslash

Why isn't this "\\" like the other data ("\n")?

>The backslash MUST NOT be followed by any other character.

Seems reasonable.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Jan 2017 08:05:05 +0100

> On 18 Jan 2017, at 22:08, Phil Shafer <[email-masked]> wrote:
> 

The second backslash was eaten along the way. On the errata web page it is correct.

Lada

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Jan 2017 12:23:51 -0500

Martin,

> The solution moving forward is to use YANG 1.1.

IMO this highlights why 1.1 probably should have at least been
identified as updating 1.0...

I have no idea that it would take to just change this, but I suspect it
might be a new RFC.  I'll ask the rfc-editor about the process (no
change being made at this time...)

Lou

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Jan 2017 11:29:25 +0100

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 11:46:55 +0100

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:
>     - 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.
> 
> Regarding the "update" solution, see the RFC 7950 writeup at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 12:05:59 +0100 (CET)

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Jan 2017 12:08:45 +0100

On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
> ambiguous and provide advice that they should not be used.
That would work.
Can we modify the errata this way.

Regards, Benoit
> This is

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jan 2017 13:37:30 +0100

> go beyond the scope of an errata.

But it is not really the case here because it cannot be decided what
conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
don't think it is less conforming than any other.

> backwards compatible. Making them illegal is not backwards compatible.

This would be fine for the "Notes" part but RFC Errata require also
"Original Text" and "Corrected Text". Any suggestion for this?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 14:39:39 +0100

> don't think it is less conforming than any other.

Exactly. But other interpretations are legal as well. We can not
retroactively turn so far conforming implementations of the RFC into
non-conforming implementations (via an errata that introduces a MUST
that was not there in the beginning).

Corrected Text
-------------

  \n      new line
  \t      a tab character
  \"      a double quote
  \\      a single backslash

The interpretation of any other character then the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jan 2017 15:00:12 +0100

> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder <[email-masked]> wrote:
> 

OK, this looks good. Benoit, will you first reject the existing errata?

Lada

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Jan 2017 16:26:07 +0100

> OK, this looks good. Benoit, will you first reject the existing errata?
Instead of rejected, I modified the errata 4911.
A final check please before I approve it.
https://www.rfc-editor.org/errata_search.php?eid=4911

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 16:33:59 +0100 (CET)

Benoit Claise <[email-masked]> wrote:
> >> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
> >> <[email-masked]> wrote:
> >>

Hmm, I still just see the orignal errata text when I follow this link.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Jan 2017 16:41:05 +0100

> Hmm, I still just see the orignal errata text when I follow this link.
Now saved :-)

B.

---

From: Robert Wilton <[email-masked]>
Date: Mon, 23 Jan 2017 15:51:55 +0000

I would suggest tweaking the order of the words slightly:

Old:

The interpretation of any *other character then* the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

New:

The interpretation of any *character other than* the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Mon, 23 Jan 2017 11:09:53 -0500

How do you feel about an errata on 1.0 that it should be considered to
be updated by 1.1?

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jan 2017 17:26:20 +0100

> On 23 Jan 2017, at 16:51, Robert Wilton <[email-masked]> wrote:
> 
> The interpretation of any character other than the ones listed above

+1

Otherwise I like the text.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 18:08:03 +0100

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Jan 2017 18:18:46 +0100

> Otherwise I like the text.
Good.
Errata approved.

Regards, B.

---

From: Lou Berger <[email-masked]>
Date: Mon, 23 Jan 2017 12:20:48 -0500

I think we need something.  BTW I'm fine with obsoletes ;-)