RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 15 records.

Status: Verified (8)

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

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

Status: Reported (1)

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

Source of RFC: netmod (ops)

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

Reported By: Ladislav Lhotka
Date Reported: 2019-10-22

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.

Status: Held for Document Update (1)

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

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.

Status: Rejected (5)

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

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