RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 22 records.

Status: Verified (18)

RFC 6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", October 2010

Source of RFC: netmod (ops)

Errata ID: 2949
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Andy Bierman
Date Reported: 2011-08-28
Verifier Name: Dan Romascanu
Date Verified: 2011-09-05

Section 12 says:

(top of page 149)

 leafref-specification =
                         ;; these stmts can appear in any order
                         path-stmt stmtsep
                         [require-instance-stmt stmtsep]

It should say:

 leafref-specification = path-stmt stmtsep

Notes:

require-instance-stmt not allowed in leafref

Errata ID: 3087
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Martin Bjorklund
Date Reported: 2012-01-09
Verifier Name: Dan Romascanu
Date Verified: 2012-01-11

Section 12 says:

   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]
                          "}")


It should say:

  deviate-add-stmt    = deviate-keyword sep add-keyword 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]
                          "}")

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

   deviate-replace-stmt = deviate-keyword sep replace-keyword 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]
                          "}")

Notes:

The comment "these stmts can appear in any order" is missing from these three statements.

Errata ID: 3094
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Emmanuel Nataf
Date Reported: 2012-01-20
Verifier Name: Dan Romascanu
Date Verified: 2012-01-23

Section 12 says:

   bit-stmt            = bit-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [position-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                            "}"
                          "}")

It should say:

   bit-stmt            = bit-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [position-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

Notes:

An extra "}"

Errata ID: 3288
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Martin Björklund
Date Reported: 2012-07-20
Verifier Name: Benoit Claise
Date Verified: 2012-07-26

Section 7.12.1 says:

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | augment      | 7.15    | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | refine       | 7.12.2  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

It should say:

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | augment      | 7.15    | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | refine       | 7.12.2  | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

Notes:

The cardinality for 'augment' and 'refine' is '0..n'

Errata ID: 3289
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Martin Björklund
Date Reported: 2012-07-20
Verifier Name: Benoit Claise
Date Verified: 2012-07-26

Section 12 says:

   descendant-schema-nodeid =
                         node-identifier
                         absolute-schema-nodeid

It should say:

   descendant-schema-nodeid =
                         node-identifier
                         [absolute-schema-nodeid]

Notes:

A single node identifier is a valid descendant-schema-nodeid.

Errata ID: 3290
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Martin Björklund
Date Reported: 2012-07-20
Verifier Name: Benoit Claise
Date Verified: 2012-07-26

Section 12 says:

   decimal64-specification = fraction-digits-stmt

It should say:

   decimal64-specification = ;; these stmts can appear in any order
                             fraction-digits-stmt
                             [range-stmt stmtsep]

Notes:

A decimal64 type can be restricted with the "range" statement.

Errata ID: 3470
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ladislav Lhotka
Date Reported: 2013-01-24
Verifier Name: Benoit Claise
Date Verified: 2013-02-12

Section 7.16.2 says:

An identity MUST NOT reference itself, neither directly nor 
indirectly through a chain of other identities.

It should say:

The derivation of identities has the following properties:

o It is irreflexive, which means that an identity is not derived from 
  itself.

o It is transitive, which means that if identity B is derived from A
  and C is derived from B, then C is also derived from A.

Notes:

The desired properties of identity derivation are not clearly stated. The discussion in the NETMOD mailing led to a general agreement that identity derivation is supposed to be irreflexive and transitive. These two properties together also eliminate the possibility of a circular derivation.

Errata ID: 3493
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jernej Tuljak
Date Reported: 2013-02-24
Verifier Name: Benoit Claise
Date Verified: 2013-02-24

Section 12 says:

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

It should say:

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

Errata ID: 3495
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jernej Tuljak
Date Reported: 2013-02-25
Verifier Name: Benoit Claise
Date Verified: 2013-02-28

Section 12 says:

   revision-stmt       = revision-keyword sep revision-date optsep
                         (";" /
                          "{" stmtsep
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

It should say:

   revision-stmt       = revision-keyword sep revision-date optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

Notes:

The comment "these stmts can appear in any order" is missing from this statement.

Errata ID: 3832
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Chris LaBauve
Date Reported: 2013-12-12
Verifier Name: Benoit Claise
Date Verified: 2013-12-13

Section 7.4.1 says:

               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

It should say:

               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | base             | 9.10.2  | 0..1        |
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | fraction-digits  | 9.3.4   | 0..1        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

Notes:

9.3.4. states 'The "fraction-digits" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "fraction-digits" as one of the substatements of "type".

9.10.2. states 'The "base" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "base" as one of the substatements of "type".

Errata ID: 3835
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Chris LaBauve
Date Reported: 2013-12-12
Verifier Name: Benoit Claise
Date Verified: 2013-12-13

Section 12 says:

   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification

It should say:

   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification / 
                         binary-specification

   binary-specification = [length-stmt stmtsep]

Notes:

Grammar rule 'type-body-stmts' does not provide for the case when type is 'binary'; this would be a rule allowing 0 or 1 length substatements according to 9.8.1.

Errata ID: 3842
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ladislav Lhotka
Date Reported: 2013-12-13
Verifier Name: Benoit Claise
Date Verified: 2013-12-17

Section 9.4.4 says:

It is used to restrict the built-in type "string", or types derived
from "string".

It should say:

It is used to restrict the built-in types "string" and "binary", or
types derived from them.

Notes:

The "length" statement can also restrict the "binary" type. See also erratum 3835.

Errata ID: 3871
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jonathan Hansford
Date Reported: 2014-01-23
Verifier Name: Benoit Claise
Date Verified: 2014-02-01

Section 9.6.4.2 says:

If a value is not specified, then one will be automatically assigned.
If the "enum" substatement is the first one defined, the assigned
value is zero (0); otherwise, the assigned value is one greater than
the current highest enum value.

It should say:

If a value is not specified, then one will be automatically assigned.
If the "enum" substatement is the first one defined, the assigned
value is zero (0); otherwise, the assigned value is one greater than
the current highest enum value (that is, the highest enum value,
implicit or explicit, prior to the current "enum" substatement in
the parent "type" statement).

Notes:

Clarification that 'current highest' does not refer to all enum values, implicit or explicit, in the parent "type" statement but only to those that precede the current "enum" substatement.

Errata ID: 3872
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jonathan Hansford
Date Reported: 2014-01-23
Verifier Name: Benoit Claise
Date Verified: 2014-02-01

Section 9.7.4.2 says:

If a bit position is not specified, then one will be automatically
assigned. If the "bit" substatement is the first one defined, the
assigned value is zero (0); otherwise, the assigned value is one
greater than the current highest bit position.

It should say:

If a bit position is not specified, then one will be automatically
assigned. If the "bit" substatement is the first one defined, the
assigned value is zero (0); otherwise, the assigned value is one
greater than the current highest bit position (that is, the
highest bit position, implicit or explicit, prior to the current
"bit" substatement in the parent "type" statement).

Notes:

Clarification that 'current highest' does not refer to all bit positions, implicit or explicit, in the parent "type" statement but only to those that precede the current "bit" substatement.

Errata ID: 4282
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Cesar Crusius
Date Reported: 2015-02-27
Verifier Name: Benoit Claise
Date Verified: 2015-03-11

Section 12 says:

unknown-statement   = prefix ":" identifier [sep string] optsep
                      (";" / "{" *unknown-statement2 "}") 
unknown-statement2   = [prefix ":"] identifier [sep string] optsep
                      (";" / "{" *unknown-statement2 "}") 

It should say:

unknown-statement   = prefix ":" identifier [sep string] optsep
                    (";" / "{" optsep *(unknown-statement2 optsep) "}")
unknown-statement2   = [prefix ":"] identifier [sep string] optsep
                     (";" / "{" optsep *(unknown-statement2 optsep) "}")

Errata ID: 4283
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Cesar Crusius
Date Reported: 2015-02-28
Verifier Name: Benoit Claise
Date Verified: 2015-03-11

Section 12 says:

stmtend = ";" / "{" *unknown_statement "}"

It should say:

stmtend = optsep (";" / "{" stmtsep "}") stmtsep

Notes:

Note1: As specified, there are no spaces allowed between the unknown statements, and between the braces and the unknown statements.

Notes2:
The original "stmtend" rule does not allow for spaces between unknown
statements, which requires the "*unknown-statement" fix in "stmtend".

There is at least one place ("revision-date-stmt") where "stmtend" end
is not preceded by "optsep". Instead of fixing those rules, it is better to
include "optsep" in "stmtend" itself, since it should always be present.

On the same note, almost all "stmtend" uses are followed by a
"stmtsep", and any cases where that does not happen are probably an error, so again it is better to make that explicit in the "stmtend" rule itself.

With the change in this errata, there will be a lot of rules in the
ABNF with redundant (but not technically incorrect) "optsep" and "stmtsep" parts, as for example

module-header-stmts = ;; these stmts can appear in any order
[yang-version-stmt stmtsep]
namespace-stmt stmtsep
prefix-stmt stmtsep

namespace-stmt = namespace-keyword sep uri-str optsep stmtend

which now could be replaced with

module-header-stmts = ;; these stmts can appear in any order
[yang-version-stmt]
namespace-stmt
prefix-stmt

namespace-stmt = namespace-keyword sep uri-str stmtend

These changes should probably be incorporated into the next ABNF
revision.

Errata ID: 4292
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Cesar Crusius
Date Reported: 2015-03-07
Verifier Name: Benoit Claise
Date Verified: 2015-03-10

Section 12 says:

   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              type-body-stmts
                          "}")

It should say:

   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              [ type-body-stmts ]
                          "}")

Notes:

Every statement that can end with a single ';' should also accept ending with '{ stmtsep }' (that is what the 'stmtend' rule implies). This is the only instance I found so far of a statement that does not follow this rule.

The other option would be to replace all ";" in rules like that with 'stmtend'.

Errata ID: 4911
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ladislav Lhotka
Date Reported: 2017-01-18
Verifier Name: Benoit Claise
Date Verified: 2017-01-23

Section 6.1.3 says:

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

It should say:

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

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.

Status: Held for Document Update (1)

RFC 6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", October 2010

Source of RFC: netmod (ops)

Errata ID: 3834
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Chris LaBauve
Date Reported: 2013-12-12
Held for Document Update by: Benoit Claise
Date Held: 2013-12-13

Section 9.7.5 says:

    Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit 10-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and 10-Mb-only set would be:

     <mybits>disable-nagle 10-Mb-only</mybits>

It should say:

    Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit ten-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and ten-Mb-only set would be:

     <mybits>disable-nagle ten-Mb-only</mybits>

Notes:

9.7.5. Shows a usage example of the bit statement wherein the identifier '10-Mb-only' begins with a digit, which contradicts the ABNF rule 'identifier' (identifier must begin with [_A-Za-z])

Status: Rejected (3)

RFC 6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", October 2010

Source of RFC: netmod (ops)

Errata ID: 4285
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Cesar Crusius
Date Reported: 2015-03-02
Rejected by: Benoit Claise
Date Rejected: 2015-03-10

Section 12 says:

revision-date-stmt = revision-date-keyword sep revision-date stmtend

It should say:

revision-date-stmt =
    revision-date-keyword sep revision-date optsep stmtend

Notes:

Allow spaces between the date string and the statement's end.
--VERIFIER NOTES--
This errata is now covered by the updated errata 4283

Errata ID: 5272
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Bob Harold
Date Reported: 2018-03-02
Rejected by: Benoit Claise
Date Rejected: 2018-03-06

Section 7.18.1 says:

   In order for a device to implement a feature that is dependent on any
   other features (i.e., the feature has one or more "if-feature" sub-
   statements), the device MUST also implement all the dependant
   features.

It should say:

   In order for a device to implement a feature that is dependent on any
   other features (i.e. the feature is a sub-statement of another 
   "if-feature" statement), the device MUST also implement all the 
   dependent features.

Notes:

The direction of the dependency is stated backwards.
Consider for example:

if-feature aaa;
statements ...;
if-feature bbb;

This should allow feature aaa to exist without feature bbb.
bbb should depend on aaa, but aaa should not depend on bbb
--VERIFIER NOTES--
The current text is correct, according to Kent Watsen

Errata ID: 4291
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Cesar Crusius
Date Reported: 2015-03-07
Rejected by: Benoit Claise
Date Rejected: 2015-03-10

Section 12 says:

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

It should say:

   deviate-not-supported-stmt =
                         deviate-keyword sep
                         not-supported-keyword
                         stmtend

Notes:

The rule is not incorrect, but unnecessarily replicates 'stmtend' within it.
--VERIFIER NOTES--
This is already fixed in draft-ietf-netmod-rfc6020bis-04.

Since this is not really a bug, I don't know if it is worth the effort
to accept this errata.

Report New Errata



Advanced Search