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 >
…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.
Br,
Peter
From: Andy Bierman <[email protected]>
Sent: den 21 februari 2019 18:45
To: Martin Bjorklund <[email protected]>
Cc: RFC Editor <[email protected]>; Ignas Bagdonas
<[email protected]>; NetMod WG <[email protected]>; Peter Loborg
<[email protected]>; Warren Kumari <[email protected]>
Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)
On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund
<[email protected]<mailto:[email protected]>> wrote:
RFC Errata System <[email protected]<mailto:[email protected]>>
wrote:
> 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 protected]<mailto:[email protected]>>
>
> 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.
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';
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.
/martin
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:
> -------------
> 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
>
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
