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

From: RFC Errata System <[email-masked]>
Date: Sun, 24 Feb 2013 01:17:22 -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=3493

--------------------------------------
Type: Technical
Reported by: Jernej Tuljak <[email-masked]>

Section: 12

Original Text
-------------
value-stmt          = value-keyword sep integer-value stmtend

Corrected Text
--------------
value-stmt          = value-keyword sep integer-value-arg-str stmtend

integer-value-arg-str   = < a string that matches the rule
                           integer-value-arg >

integer-value-arg       = integer-value

Notes
-----
Value statement should follow the rules for specifying YANG statement arguments. Current grammar does not allow a quoted string to appear as an argument to a value-stmt. Published IETF YANG modules exist which assume a quoted string may appear as an argument to this statement (eg. ietf-inet-types).

Instructions:
-------------
This errata 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 (IESG)
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: Jernej Tuljak <[email-masked]>
Date: Sun, 24 Feb 2013 11:15:31 +0100

I believe deviate statements also suffer from a similar problem. "add",
"replace", "delete" and "not-supported" are defined as grammar keywords and
also get used directly in productions instead through <a string that
matches...>, meaning that they also must not be quoted. Was this
intentional?

As a side note, since it also relates to quoting:

I've noticed that some published IETF modules contain statements such as:

pattern "[\.0-9]*";

This is an example of illegal quoting. In double quoted strings a backslash
('\') represents a YANG escape sequence. There are only four such sequences
possible: \n, \t, \" and \\. Sequence \. is not allowed and in fact the
correct way of specifying the above pattern statement would be:

pattern "[\\.0-9]*";

That's how I understood "6.1.3 Quoting". You should avoid using double
quotes for specifying regular expressions and use single quotes instead
(unless the regex contains a single quote character).

I've taken the example from draft-ietf-netmod-rfc6021-bis-00 (!).

As another side note, the grammar specified by RFC6020 is inherently
ambiguous in the definition of refine-stmt. If an implementor were to try
to implement a parser based on that ABNF and strictly follow the
productions listed in there, she would eventually stumble upon this
refine-stmt production. It contains an alternation between
refine-container-stmts, refine-leaf-stmts, etc. It is impossible to
determine which alternative should be taken by the parser unless you
resolve refine-arg-str (a job for a compiler not a parser). Perhaps a
comment should be added in there to warn people about it. The reason for
ambiguity is the fact that this alternation is supposed to decide between
alternatives that contain non-terminals from the same super-set and no
terminals that would make the decision between them possible.

Jernej

2013/2/24 RFC Errata System <[email-masked]>

> Value statement should follow the rules for specifying YANG statement
> arguments. Current grammar does not allow a quoted string to appear as an
> argument to a value-stmt. Published IETF YANG modules exist which assume a
> quoted string may appear as an argument to this statement (eg.
> ietf-inet-types).
>
> Instructions:
> -------------
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Feb 2013 11:26:52 +0100

> I've taken the example from draft-ietf-netmod-rfc6021-bis-00 (!).

I have fixed the broken pattern.

/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: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Feb 2013 20:29:25 +0100 (CET)

Hi,

I agree that this is a proper correction.

/martin

RFC Errata System <[email-masked]> wrote:
> quoted string may appear as an argument to this statement
> (eg. ietf-inet-types).
> 
> Instructions:
> -------------

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Feb 2013 20:29:47 +0100 (CET)

> matches...>, meaning that they also must not be quoted. Was this

Nope, this is also a bug,

/martin

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 25 Feb 2013 09:06:41 +0100

> Nope, this is also a bug,

There's an existing errata (3087) dealing with deviate-add-stmt, 
deviate-delete-stmt and deviate-replace-stmt (but not 
deviate-not-stupported-stmt). I think it would be confusing if we posted 
another errata which refers to the same text. If possible, 3087 should 
be edited so it becomes something like this;

Old (RFC text, not errata text):

    deviate-not-supported-stmt =
                          deviate-keyword sep
                          not-supported-keyword optsep
                          (";" /
                           "{" stmtsep
                           "}")

    deviate-add-stmt    = deviate-keyword sep add-keyword optsep
                          (";" /
                           "{" stmtsep
                               [units-stmt stmtsep]
                               *(must-stmt stmtsep)
                               *(unique-stmt stmtsep)
                               [default-stmt stmtsep]
                               [config-stmt stmtsep]
                               [mandatory-stmt stmtsep]
                               [min-elements-stmt stmtsep]
                               [max-elements-stmt stmtsep]
                           "}")

    deviate-delete-stmt = deviate-keyword sep delete-keyword optsep
                          (";" /
                           "{" stmtsep
                               [units-stmt stmtsep]
                               *(must-stmt stmtsep)
                               *(unique-stmt stmtsep)
                               [default-stmt stmtsep]
                           "}")

    deviate-replace-stmt = deviate-keyword sep replace-keyword optsep
                          (";" /
                           "{" stmtsep
                               [type-stmt stmtsep]
                               [units-stmt stmtsep]
                               [default-stmt stmtsep]
                               [config-stmt stmtsep]
                               [mandatory-stmt stmtsep]
                               [min-elements-stmt stmtsep]
                               [max-elements-stmt stmtsep]
                           "}")

New:

    deviate-not-supported-stmt =
                          deviate-keyword sep
                          not-supported-arg-str optsep
                          (";" /
                           "{" stmtsep
                           "}")

    not-supported-arg-str   = < a string that matches the rule
                            not-supported-arg >

    not-supported-arg       = not-supported-keyword

    deviate-add-stmt    = deviate-keyword sep add-arg-str optsep
                          (";" /
                           "{" stmtsep
                               ;; these stmts can appear in any order
                               [units-stmt stmtsep]
                               *(must-stmt stmtsep)
                               *(unique-stmt stmtsep)
                               [default-stmt stmtsep]
                               [config-stmt stmtsep]
                               [mandatory-stmt stmtsep]
                               [min-elements-stmt stmtsep]
                               [max-elements-stmt stmtsep]
                           "}")

    add-arg-str   = < a string that matches the rule
                            add-arg >

    add-arg       = add-keyword

    deviate-delete-stmt = deviate-keyword sep delete-arg-str optsep
                          (";" /
                           "{" stmtsep
                               ;; these stmts can appear in any order
                               [units-stmt stmtsep]
                               *(must-stmt stmtsep)
                               *(unique-stmt stmtsep)
                               [default-stmt stmtsep]
                           "}")

    delete-arg-str   = < a string that matches the rule
                            delete-arg >

    delete-arg       = delete-keyword

    deviate-replace-stmt = deviate-keyword sep replace-arg-str optsep
                          (";" /
                           "{" stmtsep
                               ;; these stmts can appear in any order
                               [type-stmt stmtsep]
                               [units-stmt stmtsep]
                               [default-stmt stmtsep]
                               [config-stmt stmtsep]
                               [mandatory-stmt stmtsep]
                               [min-elements-stmt stmtsep]
                               [max-elements-stmt stmtsep]
                           "}")

    replace-arg-str   = < a string that matches the rule
                            replace-arg >

    replace-arg       = replace-keyword

Note: The comment "these stmts can appear in any order" is missing from 
deviate-add-stmt, deviate-delete-stmt and deviate-replace-stmt 
productions. Deviate statements should follow the rules for specifying 
YANG statement arguments. Current grammar does not allow a quoted string 
to appear as an argument to a deviate statement.

In addition to the "any order" comment for the latter three statements, 
there's a <a string that matches...> for every deviate argument. I 
checked and none of the new non-terminals I propose clash with existing 
ones.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Feb 2013 09:38:23 +0100

> terminals that would make the decision between them possible.

This is a correct observation, the ABNF tries to be too specific here. IMO it would be better to use the same approach as for augment-stmt for which the ABNF allows, for example, to augment a container with a case node - this is of course an error, but a semantic one.

The non-ambiguous version would be:

   refine-stmt         = refine-keyword sep refine-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             *(must-stmt stmtsep)
                             [presence-stmt stmtsep]
                             [default-stmt stmtsep]
                             [config-stmt stmtsep]
                             [mandatory-stmt stmtsep]
                             [min-elements-stmt stmtsep]
                             [max-elements-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                         "}"

Lada

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

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 25 Feb 2013 09:55:54 +0100

>                               [description-stmt stmtsep]

Yes. This is what I was forced to do while implementing this grammar 
with JavaCC. The rest of it appears to be non ambiguous or it's 
ambiguity may be resolved by changing the order of productions and 
relying on lookahead for choosing correct alternations (there's just one 
case of this in type-body-stmts if I remember correctly).

Jernej