RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 14 records.

Status: Verified (13)

RFC 7950, "The YANG 1.1 Data Modeling Language", August 2016

Note: This RFC has been updated by RFC 8342, RFC 8526

Source of RFC: netmod (ops)

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

Reported By: Ladislav Lhotka
Date Reported: 2016-09-02
Verifier Name: Benoit Claise
Date Verified: 2016-09-14

Section 7.21.5 says:

   o  If the "when" statement is a child of an "augment" statement, then
      the context node is the augment's target node in the data tree, if
      the target node is a data node.  Otherwise, the context node is
      the closest ancestor node to the target node that is also a data
      node.  If no such node exists, the context node is the root node.
      The accessible tree is tentatively altered during the processing
      of the XPath expression by removing all instances (if any) of the
      nodes added by the "augment" statement.

It should say:

   o  If the "when" statement is a child of an "augment" statement, then
      the context node is the augment's target node in the data tree, if
      the target node is a data node, rpc, action or notification.
      Otherwise, the context node is the closest ancestor node to the
      target node that is also a data node, rpc, action or notification.
      If no such node exists, the context node is the root node. The
      accessible tree is tentatively altered during the processing of
      the XPath expression by removing all instances (if any) of the
      nodes added by the "augment" statement.

Notes:

If the target node of an "augment" is inside an rpc, action or notification, the context node also needs to be inside that rpc, action or notification. For example, if the target node is the "input" node of an action, the context node should be the action node, not the data node for which the action is defined as the original text implies. This is also in accordance with the definition of the accessible tree in Sec. 6.4.1.

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

Reported By: Michal Vasko
Date Reported: 2017-01-24
Verifier Name: Benoit Claise
Date Verified: 2017-01-25

Section 7.17. says:

If the target node is a container, list, case, input, output, or
notification node, the "container", "leaf", "list", "leaf-list",
"uses", and "choice" statements can be used within the "augment"
statement.

It should say:

If the target node is a container, list, case, input, output, or
notification node, the "anydata", "anyxml", "container", "leaf",
"list", "leaf-list", "uses", and "choice" statements can be used
within the "augment" statement.

Notes:

It was forgotten to mention "anydata" and "anyxml" as valid substatements in this case.

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

Reported By: Kent Watsen
Date Reported: 2018-03-04
Verifier Name: Benoit Claise
Date Verified: 2018-03-05

Section 7.16.3 says:

   A corresponding XML instance example of the complete notification:

     <notification
       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2008-07-08T00:01:00Z</eventTime>
       <event xmlns="urn:example:event">
         <event-class>fault</event-class>
         <reporting-entity>
           /ex:interface[ex:name='Ethernet0']
         </reporting-entity>
         <severity>major</severity>
       </event>
     </notification>

It should say:

   A corresponding XML instance example of the complete notification
   follows.  This example reports an event for an interface from the
   "example-foo" module defined in Section 13.1.1.

     <notification
       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2008-07-08T00:01:00Z</eventTime>
       <event xmlns="urn:example:event">
         <event-class>fault</event-class>
         <reporting-entity xmlns:ex="urn:example:foo">
           /ex:interface[ex:name='Ethernet0']
         </reporting-entity>
         <severity>major</severity>
       </event>
     </notification>

Notes:

The "ex" prefix is not declared. The "example-foo" module in 13.1.1 is the only module in the draft that matches the given instance-identifier. An alternative fix would be to use a different module and a matching instance-identifier.

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

Reported By: Andreas Jakobik
Date Reported: 2018-09-03
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-07-01

Section 7.20.3.2 says:

The argument "delete" deletes properties from the target node.  The
   properties to delete are identified by substatements to the "delete"
   statement. 

It should say:

The argument "delete" deletes properties from the target node.  The
   properties to delete are identified by substatements to the "deviate"
   statement. 

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

Reported By: Rohit R Ranade
Date Reported: 2018-10-08
Verifier Name: Joel Jaeggli
Date Verified: 2019-09-24

Section 10.4.2 says:

The derived-from-or-self() function returns "true" if any node in the
   argument "nodes" is a node of type "identityref" and its value is an
   identity that is equal to or derived from (see Section 7.18.2) the
   identity "identity"; otherwise, it returns "false".

It should say:

 The derived-from-or-self() function returns "true" if any node in the
 argument "nodes" is a node of type "identityref" or a type derived
 from "identityref", and its value is an identity that is equal to or
 derived from (see Section 7.18.2) the identity "identity"; 
 otherwise, it returns "false".

Notes:

The node-set can have node which are of types that may be derived from an identityref. Typical example is in ietf-netconf-nmda, where "when 'derived-from-or-self(datastore, "ds:operational")';" is used, but the "datastore" node is of type "datastore-ref" defined in ietf-datastores module, which is in-turn derived from "identityref"

corrected text proposal with additional editing by Martin Bjorklund and Ladislav Lhotka

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

Reported By: Jernej Tuljak
Date Reported: 2019-08-13
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-09-09

Section 7.21.5. says:

   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the node with the "when" statement that is also a data
      node.  If no such node exists, the context node is the root node.
      The accessible tree is tentatively altered during the processing
      of the XPath expression by removing all instances (if any) of the
      nodes added by the "uses", "choice", or "case" statement.

It should say:

   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the node with the "when" statement that is also a data
      node, rpc, action or notification.  If no such node exists, the
      context node is the root node. The accessible tree is tentatively
      altered during the processing of the XPath expression by removing
      all instances (if any) of the nodes added by the "uses",
      "choice", or "case" statement.

Notes:

Similar to verified errata 4794 (https://www.rfc-editor.org/errata/eid4794) but covers the "uses", "choice" and "case" corner case (instead of "augment"). If the node for which the "when" statement is defined is within an rpc, action or notification, the context node also needs to be inside that rpc, action or notification. There are published IETF modules, which rely on this to be true, such as "ietf-netconf-nmda@2019-01-07" in RFC8526 (https://tools.ietf.org/html/rfc8526) at schema node id "/ncds:get-data/ncds:input/ncds:origin-filters". Original text assigns the context node to the root node, if no data node ancestor is found. "rpc", "action" and "notification" are not data nodes and are represented by nodes that are descendants of the root node, as described in Section 6.4.1.

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

Reported By: Michal Vasko
Date Reported: 2020-04-03
Verifier Name: Rob Wilton
Date Verified: 2020-04-03

Section 6.4. says:

   For example, consider the following definition:

     leaf lxiv {
       type decimal64 {
         fraction-digits 18;
       }
       must ". <= 10";
     }

   An instance of the "lxiv" leaf having the value of
   10.0000000000000001 will then successfully pass validation.

It should say:

   For example, consider the following definition:

     leaf lxiv {
       type decimal64 {
         fraction-digits 18;
       }
       must ". <= 9";
     }

   An instance of the "lxiv" leaf having the value of
   9.0000000000000001 will then successfully pass validation.

Notes:

Value 10.0000000000000001 is not a valid decimal64 value with 18 fraction digits as per Section 9.3.4.

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

Reported By: Fred Gan
Date Reported: 2020-08-20
Verifier Name: Robert Wilton
Date Verified: 2024-01-12

Section 5.6.5 says:

For example, with these modules:

     module a {
       yang-version 1.1;
       namespace "urn:example:a";
       prefix "a";

       import b {
         revision-date 2015-01-01;
       }
       import c;

       revision 2015-01-01;

It should say:

For example, with these modules:

     module a {
       yang-version 1.1;
       namespace "urn:example:a";
       prefix "a";

       import b {
         revision-date 2015-01-01;
         prefix b;
       }
       import c {
         prefix c;
       }

       revision 2015-01-01;

Notes:

As is considered in 7.1.5, The mandatory "prefix" substatement assigns a prefix for the imported module that is scoped to the importing module or submodule.

So, there should be a prefix substatement in the "import b" and "import c" statement respectively.

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

Reported By: Jernej Tuljak
Date Reported: 2021-05-04
Verifier Name: Rob Wilton
Date Verified: 2021-05-10

Section 11 says:

   o  New typedefs, groupings, rpcs, notifications, extensions,
      features, and identities may be added.

It should say:

   o  New typedefs, groupings, rpcs, actions, notifications,
      extensions, features, and identities may be added.

Notes:

The original text unintentionally fails to mention actions. A definition in a published module may be revised by adding actions to this definition.

Errata ID: 5237
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Muly Ilan
Date Reported: 2018-01-18
Verifier Name: Benoit Claise
Date Verified: 2018-01-18

Section 6.4.1.1 says:

The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "when" parameter set to "10" would be:

<a xmlns="urn:example:a">
<b>
<id>1</id>
<reset>
<delay>10</delay>
</reset>
</b>
<b>
<id>2</id>
</b>
</a>
// possibly other top-level nodes here

It should say:

The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "delay" parameter set to "10" would be:

<a xmlns="urn:example:a">
<b>
<id>1</id>
<reset>
<delay>10</delay>
</reset>
</b>
<b>
<id>2</id>
</b>
</a>
// possibly other top-level nodes here

Notes:

The example action "reset" has an input parameter named "delay" and not a parameter named "when".

Errata ID: 5698
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Andy Bierman
Date Reported: 2019-04-18
Verifier Name: Ignas Bagdonas
Date Verified: 2019-04-24

Section 7.5.4.3 says:

     container interface {
       leaf ifType {
         type enumeration {
           enum ethernet;
           enum atm;
         }
       }
       leaf ifMTU {
         type uint32;
       }
       must 'ifType != "ethernet" or ifMTU = 1500' {
         error-message "An Ethernet MTU must be 1500";
       }
       must 'ifType != "atm" or'
          + ' (ifMTU <= 17966 and ifMTU >= 64)' {
         error-message "An ATM MTU must be 64 .. 17966";
       }
     }

It should say:

     container interface {
       leaf ifType {
         type enumeration {
           enum ethernet;
           enum atm;
         }
       }
       leaf ifMTU {
         type uint32;
       }
       must 'string(ifType) != "ethernet" or ifMTU = 1500' {
         error-message "An Ethernet MTU must be 1500";
       }
       must 'string(ifType) != "atm" or'
          + ' (ifMTU <= 17966 and ifMTU >= 64)' {
         error-message "An ATM MTU must be 64 .. 17966";
       }
     }

Notes:

The intent of the example is for each must-stmt to be false if the ifType leaf does not exist.
However the XPath is incorrect.

From the XPath 1.0 spec, section 3.4, para 5

If one object to be compared is a node-set and the other is a string, then the comparison will be true if and only if there is a node in the node-set such that the result of performing the comparison on the string-value of the node and the other string is true.

The empty node-set is not implicitly converted to an empty string for a = or != comparison.
Instead the string() function must explicitly convert the node-set to a string

Errata ID: 6655
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Viktor Leijon
Date Reported: 2021-08-06
Verifier Name: Rob Wilton
Date Verified: 2021-10-12

Section 10.6.1.1 says:

   leaf flags {
       type bits {
         bit UP;
         bit PROMISCUOUS
         bit DISABLED;
       }
      }

It should say:

   leaf flags {
       type bits {
         bit UP;
         bit PROMISCUOUS;
         bit DISABLED;
       }
      }

Notes:

The missing semicolon makes the YANG snippet invalid.

Errata ID: 6952
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Andy Bierman
Date Reported: 2022-05-03
Verifier Name: RFC Editor
Date Verified: 2022-05-04

Section 10.4.2.1 says:

       augment "/interface" {
         when 'derived-from-or-self(type, "exif:fast-ethernet");
         // Fast-Ethernet-specific definitions here
       }

It should say:

       augment "/interface" {
         when 'derived-from-or-self(type, "exif:fast-ethernet")';
         // Fast-Ethernet-specific definitions here
       }

Notes:

single quote to end complete string is missing

Status: Reported (1)

RFC 7950, "The YANG 1.1 Data Modeling Language", August 2016

Note: This RFC has been updated by RFC 8342, RFC 8526

Source of RFC: netmod (ops)

Errata ID: 7021
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Balazs Lengyel
Date Reported: 2022-07-12

Section 11 says:

A definition in a published module may be revised in any of the
   following ways:

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.  Note that inserting a new enum
      before an existing enum or reordering existing enums will result
      in new values for the existing enums, unless they have explicit
      values assigned to them.

It should say:

A definition in a published module may be revised in any of the
   following ways:

   o  The "revision-date" substatement of an existing "import" statement 
      may get a changed argument.


   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.  Note that inserting a new enum
      before an existing enum or reordering existing enums will result
      in new values for the existing enums, unless they have explicit
      values assigned to them.

Notes:

In section 5.1.1 it is stated that a module may be republished with an updated "import"
statement. This is needed, otherwise a user of the revision-date statement (inside an import) would never be able to migrate to a newer version of the imported module.

However in section 11. Updating a Module this change is not listed in the list of allowed updates, thus it is forbidden.

Report New Errata



Advanced Search