Subject: [netmod] [Editorial Errata Reported] RFC7950 (5642)

From: RFC Errata System <[email-masked]>
Date: Thu, 21 Feb 2019 08:39:19 -0800 (PST)

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5642

--------------------------------------
Type: Editorial
Reported by: Peter Loborg <[email-masked]>

Section: 9.6.4

Original Text
-------------
It takes as an argument a string that is the assigned name. 

Corrected Text
--------------
It takes as an argument an unquoted string that is the assigned name.

Notes
-----
Readers are not beeing made aware that careful reading of section 6.1.3 and the detailed definition of string in section 14 must be consulted.
For comming versions of this RFC it would be preferable to use a more specialized grammar token for these cases (e.g. unquoted-string).

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. 

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : Network Modeling
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Feb 2019 17:53:36 +0100 (CET)

> "The YANG 1.1 Data Modeling Language".

This is not correct.  The enum argument is not different from any
other keyword's arguments in YANG.  See e.g. the example in 9.12.4:

       type enumeration {
         enum "unbounded";
       }

The following is also legal:

         enum "unb" + 'ounded';

This errata should be rejected.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Feb 2019 18:01:26 +0100

What makes you believe

     enum "foo"

is illegal?

/js

On Thu, Feb 21, 2019 at 08:39:19AM -0800, RFC Errata System wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Feb 2019 09:45:22 -0800

> The following is also legal:

  enum "This is also legal";

9.6.4.  The "enum" Statement

   The "enum" statement, which is a substatement to the "type"
   statement, MUST be present if the type is "enumeration".  It is
   repeatedly used to specify each assigned name of an enumeration type.
   It takes as an argument a string that is the assigned name.  *The
   string MUST NOT be zero-length and MUST NOT have any leading or
   trailing whitespace characters* (any Unicode character with the
   "White_Space" property).  The use of Unicode control codes SHOULD be
   avoided.

> This errata should be rejected.

Andy

>
> >
> > Notes
> > -----
> > Readers are not beeing made aware that careful reading of section 6.1.3
> and the detailed definition of string in section 14 must be consulted.
> > For comming versions of this RFC it would be preferable to use a more
> specialized grammar token for these cases (e.g. unquoted-string).
> >
> > Instructions:
> > -------------

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Feb 2019 10:14:45 -0800

On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg <[email-masked]>
wrote:

>
>
> Your example is fine – but the gammar is ch14 specifies something
> different:
>
>
>
> enum-stmt           = enum-keyword sep string optsep
>
>                          (";" /
>
>                           "{" stmtsep
>
>                               ;; these stmts can appear in any order
>
>                               *if-feature-stmt
>
>                               [value-stmt]
>
>                               [status-stmt]
>
>                               [description-stmt]
>
>                               [reference-stmt]
>
>                            "}") stmtsep
>
>
>
> It clearly states  string, not quoted-string. These two have the following
> rules:
>
>
>
> quoted-string       = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
>
>
>
> string              = < an unquoted string, as returned by >
>
>                          < the scanner, that matches the rule >
>
>                          < yang-string >
>
>
>

The text in 9.6.4 is correct.
The ABNF is wrong.

> …and in 6.1.3 we can read that:
>
>    An unquoted string is any sequence of characters that does not
>
>    contain any space, tab, carriage return, or line feed characters, a
>
>    single or double quote character, a semicolon (";"), braces ("{" or
>
>    "}"), or comment sequences ("//", "/*", or "*/").
>
>
>
>    Note that any keyword can legally appear as an unquoted string.
>
>
>
> Since the section so clearly writes about single quoted strings and double
> quoted strings, there can unfortunately be no interpretation that would
> allow “identifier” to be called an unquoted string – even though it follows
> the rules about limited character contents.
>
>
>
> Hence – this is not a matter of opinion – it’s a matter of reading what’s
> actually written in the RFC.
>
>
>
> But on the subject of opinion…
>
>
>
>       enum "This is also legal";   // should definitely always be illegal
>
>
>
> …as we cannot create a language binding to enum constructs in any major
> programming languages.
>
>
>

There are many aspects of YANG that do not map directly to programming
languages,
such as allowing '.' in identifiers.

> Br,
> Peter

Andy

>
>
>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* den 21 februari 2019 18:45
> *To:* Martin Bjorklund <[email-masked]>
> *Cc:* RFC Editor <[email-masked]>; Ignas Bagdonas <
> [email-masked]>; NetMod WG <[email-masked]>; Peter Loborg <
> [email-masked]>; Warren Kumari <[email-masked]>
> *Subject:* Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)
>
>
>
>
>
>
>
>    It takes as an argument a string that is the assigned name.  *The*
>
> *   string MUST NOT be zero-length and MUST NOT have any leading or*
>
> *   trailing whitespace characters* (any Unicode character with the
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Feb 2019 19:33:25 +0100 (CET)

> The text in 9.6.4 is correct.

No, the ABNF is correct.  The ABNF doens't handle concatenation etc.
The idea is that the scanner handles quotes and concatenation and
returns a "string".

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Feb 2019 19:53:09 +0100

On Thu, Feb 21, 2019 at 05:26:43PM +0000, Peter Loborg wrote:
> The following two rules in section 14:
> 

The key here is "as returned by the scanner".
 
> ...and the definition of unquoted string in section 6.1.3 about its content... (not a problem in your example)
> 
> ...and the explicit descriptions of single-quoted strings and double-quoted strings further down in 6.1.3 as being enclosed by said quotes.

Section 6.1 defines the lexical rules and what the scanner returns is
an unquopted string but it accepts unquoted strings and quoted string
and combinations thereof with the "+" concatenation operator as input.

The errata should be rejected.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Feb 2019 10:53:45 -0800

On Thu, Feb 21, 2019 at 10:33 AM Martin Bjorklund <[email-masked]> wrote:

> > On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg <[email-masked]
> >
> > wrote:
> >
> > >
> > >

OK -- it is confusing that the rule quoted-string exists, but it
is only for key and leaf-list predicates.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Feb 2019 10:02:50 +0100

> The idea is that the scanner handles quotes and concatenation and

I guess the explanation could be improved. Section 6.1.3 talks about unquoted,
single- and double-quoted strings, but then the term "string" is used in the
ABNF to mean the argument string, i.e. the result of scanner preprocessing
(concatenation, substitution of escaped characters). Maybe we can use another
term, such as "argstring", for the latter.

Also, the term scanner only appears in the ABNF appendix. Some explanation of
the preprocessing stage in the main text would also help.

Lada

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

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 22 Feb 2019 10:55:31 +0000

Do people really use enum names with whitespace within?
I always had the feeling that the name of the enum is like an 
identifier, so it should follow maybe not the exact same but at least 
similar rules.

When such an enum name is translated into a programing language AFAIK 
the translation needs to replace the spaces with something.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Feb 2019 12:07:56 +0100

On Fri, Feb 22, 2019 at 10:55:31AM +0000, Balázs Lengyel wrote:
> I always had the feeling that the name of the enum is like an identifier, so
> it should follow maybe not the exact same but at least similar rules.
> 
> When such an enum name is translated into a programing language AFAIK the
> translation needs to replace the spaces with something.

Not just spaces. Tool implementors will have to address this and what
needs special handling varies from target language to target language
(some target languages or implementations of target languages also
have interesting length contraints).

I think it is fine if BCPs like RFC 8407 provide guidelines that
people should avoid characters that are likely to be problematic but
the YANG specification is relatively clear that YANG itself puts
little constraints on such names (and hence tool makers in charge
to handle this).

/js

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 22 Feb 2019 12:45:16 +0000

I am not asking for a change, but ...

IMHO it would be better if YANG would not allow whitespace in
enum names.

It is a rarely needed freedom that degrades usability and can lead
to mistakes

and higher tool development costs. So it is bad for both people
and tools.

It is misleading, as a human user can mistakenly think that "this
is legal" is actually 3 separate values

Some tools tend to consider spaces as separators

When creating code from YANG this needs special handling

regards Balazs

On 2019. 02. 22. 12:07, Juergen
Schoenwaelder wrote:

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Feb 2019 14:15:49 +0100

On Fri, Feb 22, 2019 at 12:45:16PM +0000, Balázs Lengyel wrote:
>    IMHO it would be better if YANG would not allow whitespace in enum names.
>    It is a rarely needed freedom that degrades usability and can lead to
>    mistakes
>    and higher tool development costs. So it is bad for both people and tools.
> 
>      * It is misleading, as a human user can mistakenly think that "this is
>        legal" is actually 3 separate values
>      * Some tools tend to consider spaces as separators
>      * When creating code from YANG this needs special handling
>

Banning white space may make you feel better but it does not really
solve the problem for tool makers. There are many more restrictions
and going for the most restricted minimum gets us back to really
limiting results.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Feb 2019 15:33:44 +0100

> and going for the most restricted minimum gets us back to really

I agree. It is not terribly difficult to support enum names containing spaces in
any programming language.

Lada

---

From: Peter Loborg <[email-masked]>
Date: Thu, 21 Feb 2019 18:06:59 +0000

Your example is fine – but the gammar is ch14 specifies something different:

It clearly states  string, not quoted-string. These two have the following rules:

Since the section so clearly writes about single quoted strings and double quoted strings, there can unfortunately be no interpretation that would allow “identifier” to be called an unquoted string – even though it follows the rules about limited character contents.

Hence – this is not a matter of opinion – it’s a matter of reading what’s actually written in the RFC.

…as we cannot create a language binding to enum constructs in any major programming languages.

Br,
Peter

From: Andy Bierman <[email-masked]>
Sent: den 21 februari 2019 18:45
To: Martin Bjorklund <[email-masked]>
Cc: RFC Editor <[email-masked]>; Ignas Bagdonas <[email-masked]>; NetMod WG <[email-masked]>; Peter Loborg <[email-masked]>; Warren Kumari <[email-masked]>
Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)

On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:
> Reported by: Peter Loborg <[email-masked]<mailto:[email-masked]>>
>
> Section: 9.6.4
>
> Original Text
> -------------

       type enumeration {
         enum "unbounded";
       }

         enum "unb" + 'ounded';

   It takes as an argument a string that is the assigned name.  The

   trailing whitespace characters (any Unicode character with the

   avoided.

/martin

Andy

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Kent Watsen <[email-masked]>
Date: Wed, 27 Feb 2019 16:37:04 +0000

Note: I just released this this email.  

Peter sent it on the 22nd, but it was trapped by Mailman:  

	Post by non-member to a members-only list

Kent // co-chair

> On Feb 21, 2019, at 1:06 PM, Peter Loborg <[email-masked]> wrote:
> 
>  
> From: Andy Bierman <[email-masked] <mailto:[email-masked]>> 
> To: Martin Bjorklund <[email-masked] <mailto:[email-masked]>>
> Cc: RFC Editor <[email-masked] <mailto:[email-masked]>>; Ignas Bagdonas <[email-masked] <mailto:[email-masked]>>; NetMod WG <[email-masked] <mailto:[email-masked]>>; Peter Loborg <[email-masked] <mailto:[email-masked]>>; Warren Kumari <[email-masked] <mailto:[email-masked]>>
> On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund <[email-masked] <mailto:[email-masked]>> wrote:
> RFC Errata System <[email-masked] <mailto:[email-masked]>> wrote:
> > http://www.rfc-editor.org/errata/eid5642 <http://www.rfc-editor.org/errata/eid5642>
> > 
> > Reported by: Peter Loborg <[email-masked] <mailto:[email-masked]>>
> > 
> > Section: 9.6.4
> > 
> > Original Text
> > -------------
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>_______________________________________________
> netmod mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>