RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 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 (1)

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.

Report New Errata



Advanced Search