RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Status: Held for Document Update (2)

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: 5617
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Marek Michalak, Pawel Koch
Date Reported: 2019-01-30
Held for Document Update by: Joel Jaeggli
Date Held: 2019-10-07

Section 14 says:

path-arg            = absolute-path / relative-path

It should say:

path-arg            = deref-expr / path-str

deref-expr          = deref-function-invocation *WSP "/" *WSP 
                      relative-path

path-str            = absolute-path / relative-path

deref-function-invocation = deref-keyword *WSP
                            "(" *WSP path-str *WSP ")"

deref-keyword       = %s"deref"

Notes:

This is to allow path statement to contain also "deref" function invocation which is supported by pyang and Cisco compiler but for now is not supported by i.e. yanglint validator because of above statement which does not allow for it.

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

Reported By: Radek Krejci
Date Reported: 2020-03-27
Held for Document Update by: Robert Wilton
Date Held: 2020-05-04

Section 9.9.3 says:

The "require-instance" statement, which is a substatement to the 
"type" statement, MAY be present if the type is "instance-identifier"
or "leafref".  It takes as an argument the string "true" or "false".
If this statement is not present, it defaults to "true".

It should say:

The "require-instance" statement, which is a substatement to the
"type" statement, MAY be present if the type is "instance-identifier",
"leafref" or a type derived from them.  It takes as an argument the
string "true" or "false".  If this statement is not present, it
defaults to "true".

Notes:

The document does not specify whether the “require-instance” keyword is allowed in typedef refinements derived from the “leafref” or “instance-identifier” base types, but it is anticipated that a future revision of YANG would allow this. It is suggested that modules using YANG language versions 1 [RFC 6020] and 1.1 [RFC 7950] avoid using this construct, YANG module validation tools flag a warning if this construct is used, but implementations allow this if possible.

Status: Rejected (8)

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: 5157
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Andy Bierman
Date Reported: 2017-10-16
Rejected by: Benoit Claise
Date Rejected: 2017-10-23

Section 14 says:

  key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string

It should say:

  key-predicate-expr  = node-identifier *WSP "=" *WSP 
        (quoted-string / integer-value / decimal-value)

Notes:

An instance identifier is forced to specify every key value to be a string
even though the YANG key leaf type could be a numeric type.
XPath does not require a quoted string here, just YANG.

Old: /top/list[idx="4"]
New: /top/list[idx=4]
--VERIFIER NOTES--
Hi,

To be clear, I am withdrawing this errata because existing implementations
may not accept a numeric literal in an instance-identifier.
I think this should be addressed in YANG 2.0 and this thread should be
recorded in the yang-next issue trac ker.

Andy

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

Reported By: Ebben Aries
Date Reported: 2019-03-18
Rejected by: Joel Jaeggli
Date Rejected: 2019-10-07

Section 14 says:

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

It should say:

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

Notes:

Section 7.20.3.2 specifies all permitted substatements for the "deviate" statement however the ABNF grammar specifies different valid substatements per deviate argument. The "delete" argument is one such that only contains a subset of what is defined in the substatement table in this section.

The errata mentioned at: https://www.rfc-editor.org/errata/eid5489 is meant to correct the following statement

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

However this either needs to be a per argument table or ABNF correction
--VERIFIER NOTES--
Martin Bjorklund wrote:

I agree that the document needs clarification, and the yang-next issue
will take care of that. The document needs a clarification that the
refers to the grammar, or perhaps different substatement tables for
add/replace/delete.

Meanwhile, I think that this errata should be rejected.

rob wilton and robert varga wrote:

Hi Ebben,

I've always taken the ABNF to list the definitive sub-statements that are allowed for the various deviate "add", "replace", or "delete" options. Perhaps the RFC could state this more explicitly. Perhaps raise an issue on the YANG Next issue tracker to clarify this (https://github.com/netmod-wg/yang-next/issues) and it might get discussed tomorrow.

I agree.

Proposed statements are simple cases, for which 'deviate replace' can be
used to specify the correct value -- for example remove 'min-elements'
by replacing it with 'min-elements 0'.

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

Reported By: Qin WU
Date Reported: 2019-07-17
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2019-09-06

Section 9.3.2 says:

Leading and trailing zeros are prohibited, subject to the rule that 
there MUST be at least one digit before and after the decimal point.  
The value zero is represented as "0.0".



It should say:

Leading zeros before the first digit and trailing zeros after the 
last digit are prohibited, subject to the rule that there MUST be 
at least one digit before and after the decimal point.  The value 
zero is represented as "0.0".

Notes:

Based on the rule in the orginal text, the value such as "0.5","0.0" is illegal. So I think the intention of the original text is to make sure the leading zeros before the first digit and the trailing zero after the last digit are prohibited.
--VERIFIER NOTES--
The consensus on the NetMod WG was that this text was somewhat confusing, but understandable (and that crafting clear, concise replacement text will be ugly). I'm rejecting this, but future updates may want to consider addressing this anyway (I didn't feel it rose to the HFDU level)

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

Reported By: Ladislav Lhotka
Date Reported: 2019-10-22
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-28

Section 3 says:

o  schema tree: The definition hierarchy specified within a module.

It should say:

o  schema tree: The hierarchy of schema nodes defined in the set of all modules 
   implemented by a server, as specified in the YANG library data [RFC7895].


Notes:

The original definition of the term has two problems:

1. Schema tree is not limited to a single module. Some YANG constructs, such as augment and leafref type, may refer to a schema node that is defined in another module.

2. Apart from schema nodes, YANG modules contain definitions that do not contribute to the schema tree: groupings, typedefs, identities etc.
--VERIFIER NOTES--
Rejected based on WG discussion: https://mailarchive.ietf.org/arch/msg/netmod/5uDEBwgNehfLaPONpDSjVnCcWx8

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

Reported By: Alexei Sadovnikov
Date Reported: 2022-02-17
Rejected by: Rob Wilton
Date Rejected: 2022-02-22

Throughout the document, when it says:

7.5.  The "container" Statement
7.5.7.  XML Encoding Rules

   A container node is encoded as an XML element.  The element's local
   name is the container's identifier, and its namespace is the module's
   XML namespace (see Section 7.1.3).

   The container's child nodes are encoded as subelements to the
   container element.  If the container defines RPC or action input or
   output parameters, these subelements are encoded in the same order as
   they are defined within the "container" statement.  Otherwise, the
   subelements are encoded in any order.

7.8. The "list" Statement
7.8.5.  XML Encoding Rules

   The list's key nodes are encoded as subelements to the list's
   identifier element, in the same order as they are defined within the
   "key" statement.

   The rest of the list's child nodes are encoded as subelements to the
   list element, after the keys.  If the list defines RPC or action
   input or output parameters, the subelements are encoded in the same
   order as they are defined within the "list" statement.  Otherwise,
   the subelements are encoded in any order.
   . . . . .

7.14.  The "rpc" Statement
7.14.4.  NETCONF XML Encoding Rules

   . . . . .

   Input parameters are encoded as child XML elements to the rpc node's
   XML element, in the same order as they are defined within the "input"
   statement.

   If the RPC operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].  If output parameters are returned, they are encoded as
   child elements to the <rpc-reply> element defined in [RFC6241], in
   the same order as they are defined within the "output" statement.


7.15.  The "action" Statement
7.15.2.  NETCONF XML Encoding Rules

   . . . . .

   The <action> element contains a hierarchy of nodes that identifies
   the node in the datastore.  It MUST contain all containers and list
   nodes in the direct path from the top level down to the list or
   container containing the action.  For lists, all key leafs MUST also
   be included.  The innermost container or list contains an XML element
   that carries the name of the defined action.  Within this element,
   the input parameters are encoded as child XML elements, in the same
   order as they are defined within the "input" statement.

   . . . . .

   If the action operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].  If output parameters are returned, they are encoded as
   child elements to the <rpc-reply> element defined in [RFC6241], in
   the same order as they are defined within the "output" statement.

It should say:

7.5.  The "container" Statement
7.5.7.  XML Encoding Rules

   . . . . .

   The container's child nodes are encoded as subelements to the
   container element.  If the container defines RPC or action input or
   output parameters, these subelements MUST be encoded in the same order as
   they are defined within the "container" statement.  Otherwise, the
   subelements are encoded in any order.

7.8. The "list" Statement
7.8.5.  XML Encoding Rules

   The list's key nodes MUST be encoded as subelements to the list's
   identifier element, in the same order as they are defined within the
   "key" statement.

   The rest of the list's child nodes are encoded as subelements to the
   list element, after the keys.  If the list defines RPC or action
   input or output parameters, the subelements MUST be encoded in the same
   order as they are defined within the "list" statement.  Otherwise,
   the subelements are encoded in any order.
   . . . . .

7.14.  The "rpc" Statement
7.14.4.  NETCONF XML Encoding Rules

   . . . . .

   Input parameters MUST be encoded as child XML elements to the rpc node's
   XML element, in the same order as they are defined within the "input"
   statement.

   If the RPC operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].  If output parameters are returned, they MUST be encoded as
   child elements to the <rpc-reply> element defined in [RFC6241], in
   the same order as they are defined within the "output" statement.


7.15.  The "action" Statement
7.15.2.  NETCONF XML Encoding Rules

   . . . . .

   The <action> element contains a hierarchy of nodes that identifies
   the node in the datastore.  It MUST contain all containers and list
   nodes in the direct path from the top level down to the list or
   container containing the action.  For lists, all key leafs MUST also
   be included.  The innermost container or list contains an XML element
   that carries the name of the defined action.  Within this element,
   the input parameters MUST be encoded as child XML elements, in the same
   order as they are defined within the "input" statement.

   . . . . .

   If the action operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].  If output parameters are returned, they MUST be encoded as
   child elements to the <rpc-reply> element defined in [RFC6241], in
   the same order as they are defined within the "output" statement.

Notes:

The RFC 2119 keywords are missing in description of ordering for XML encoding rules for RPC, actions and references thereto and in additional instance of list keys encoding.

Although the text of RFC suggests reading this as if "MUST" was present, without keyword it is open to interpretation if the sentences actually mean "MUST" or "SHOULD" or may be even "MAY".

In other places discussing ordering, for example 7.7.8., 7.8.5. and 7.9.5. the "MUST" is actually present, hence proposed errata would make ordering description usage of keywords consistent.
--VERIFIER NOTES--
I can see your point of view that MUST is used in other similar places, and I'm sure that in hindsight it would be nice if the language was used consistently in equivalent places.

However, I don't think that the lack of a MUST statement makes the other text any less normative, or ambiguous. In particular, there is this paragraph of RFC 8174 that updates RFC 2119:

o These words can be used as defined here, but using them is not
required. Specifically, normative text does not require the use
of these key words. They are used for clarity and consistency
when that is what's wanted, but a lot of normative text does not
use them and is still normative.

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

Reported By: R Kaja Mohideen
Date Reported: 2022-03-16
Rejected by: Rob Wilton
Date Rejected: 2022-03-17

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.

   o  A "bits" type may have new bits added, provided the old bit
      positions do not change.  Note that inserting a new bit before an
      existing bit or reordering existing bits will result in new
      positions for the existing bits, unless they have explicit
      positions assigned to them.

It should say:

See Notes.

Notes:

When server is exposing updated yang model as mentioned in Section 11, particularly with enums, bits having new items - client systems that are not updated to use the new yang module will not be able to recognize and use the new values.

This is problematic when there are multiple clients and those systems are getting updated to catch up with yang changes over time. Updated "Client A" recognizing new enum and using it (update datastore with new value using edit-config), will make, old/not-yet-updated "Client B" to encounter the new value (received as response of get-config) that it cannot work with.

So, the "backward compatible" ways of updating a yang module should consider "multiple clients" scenario and make recommendations in such a way that clients are not forced to update all at once.
--VERIFIER NOTES--
The document text accurately represents the consensus of the WG at the time that it was published. Hence, this errata is beyond the scope of what changes could be considered as part of the errata process, such a change would need to happen via a new or updated RFC.

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

Reported By: Peter Loborg
Date Reported: 2019-02-21
Rejected by: Joel Jaeggli
Date Rejected: 2019-10-05

Section 9.6.4 says:

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

It should say:

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).
--VERIFIER NOTES--
Juergen Schoenwaelder wrote:

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.

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

Reported By: Peter Loborg
Date Reported: 2019-02-21
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2019-09-09

Section 9.6.4 says:

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

It should say:

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



--VERIFIER NOTES--
Please see the thread https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1&index=L3rZ7qFjnpsPeRJ4FfJZegWXdig for further discussions.

Report New Errata



Advanced Search