RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Held for Document Update (2)

RFC 6991, "Common YANG Data Types", July 2013

Source of RFC: netmod (ops)

Errata ID: 4076
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Andy Bierman
Date Reported: 2014-08-09
Held for Document Update by: Benoit Claise
Date Held: 2014-09-17

Section 3 says:

In date-and-time typedef description-stmt

      (c) The canonical format (see below) of data-and-time values

It should say:

      (c) The canonical format (see below) of date-and-time values

Notes:

date-and-time spelled data-and-time

Errata ID: 5105
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ladislav Lhotka
Date Reported: 2017-09-01
Held for Document Update by: Benoit Claise
Date Held: 2017-09-05

Section 3 says:

A schema node of this type will be set to zero (0) on creation
and will thereafter increase monotonically until it reaches
a maximum value of 2^32-1 (4294967295 decimal), when it
wraps around and starts increasing again from zero.

It should say:

A leaf instance of this type will be set to zero (0) on creation
and will thereafter increase monotonically until it reaches
a maximum value of 2^32-1 (4294967295 decimal), when it
wraps around and starts increasing again from zero.

Notes:

In a number of descriptions in both ietf-yang-types and ietf-inet-types, the term "schema node" is used incorrectly in places where "leaf instance" or "instance of a leaf" should be used instead. However, not all occurences of "schema node" are wrong: schema nodes just have to be distinguished from nodes in an instance data tree.

Status: Rejected (2)

RFC 6991, "Common YANG Data Types", July 2013

Source of RFC: netmod (ops)

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

Reported By: Mazhar Rana
Date Reported: 2022-07-29
Rejected by: Rob Wilton
Date Rejected: 2022-07-29

Section 4 says:

     typedef ipv4-address-no-zone {
       type inet:ipv4-address {
         pattern '[0-9\.]*';
       }
       description
         "An IPv4 address without a zone index.  This type, derived from
          ipv4-address, may be used in situations where the zone is
          known from the context and hence no zone index is needed.";
     }

It should say:

     typedef ipv4-address-no-zone {
       type inet:ipv4-address {
         pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
       }
       description
         "An IPv4 address without a zone index.  This type, derived from
          ipv4-address, may be used in situations where the zone is
          known from the context and hence no zone index is needed.";
     }

Notes:

As per RFC 4001, dotted decimal format of IPv4 address is typically written in decimal digits, formatted as four 8-bit fields that are separated by periods.
--VERIFIER NOTES--
Since the ipv4-address-no-zone type is derived from the ipv4-address
type and the ipv4-address type has the detailed pattern, there is no
need to repeat the details. An ipv4-address value has to satisfy both
the ipv4-address-no-zone pattern and the ipv4-address pattern.

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

Reported By: David Martínez García
Date Reported: 2023-09-18
Rejected by: Robert Wilton
Date Rejected: 2024-01-12

Section 3 says:

[...]

typedef object-identifier-128 {
       type object-identifier {

[...]

(and other typedefs that appear in the latest revisions of the module)

It should say:

[...]

typedef object-identifier-128 {
       type yang:object-identifier {

[...]

(and other typedefs that appear in the latest revisions of the module)

Notes:

In Section 3, the textual definition of the "ietf-yang-types" module presents, in my opinion, inconsistencies when defining typedefs that point to other typedefs in the same module: sometimes the value for the "type" key contains the prefix of the module and sometimes not. Please, see the example attached. This can also be applied to other typedefs defined in the latest revisions of the module, such as "date-no-zone" and "time-no-zone". I think this should be addressed to provide clarification and consistency, and thus can be extended to other modules and the YANG standard as well. Thanks for your time.
--VERIFIER NOTES--
As discussed on the NETMOD mailing list.: This YANG isn't wrong, and generally I don't think that YANG modules use (or should use) prefixes for types defined in the same module that they are used.

I agree that there is some inconsistency in RFC 6991 in using the "yang:" prefix, but that has been fixed by the author for the next revision of this YANG module.

Report New Errata



Advanced Search